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Executive  Summary 


The  US  Army  Informations  Systems  Command  (USAISC)  and  the 
departmental  agencies  within  the  command  are  undergoing  major 
changes  in  the  way  USAISC  does  business  as  corporate  entity.  Changes 
are  occurring  in  the  automation  of  information  and  the  exchange  of 
information  between  the  sustaining  base  in  USAISC.  ISDN  is  the 
objective  configuration  of  the  Army  to  support  and  manage  this 
information  flow.  To  effectively  evolve  to  this  objective  configuration, 
the  capabilities  and  limitations  of  ISDN  must  be  understood  so  a 
comprehensive  transitions  plan  can  be  developed.  This  Final  Report  is 
intended  to  provide  findings  and  results  stemming  from  the  AIRMICS’ 
ISDN  Research  Program  that  will  enable  the  Army  to  make  educated 
decisions  on  the  use  of  current  and  proposed  ISDN  standards  and 
applications  as  the  Army  transitions  to  the  future.  It  also  describes  the 
general  expectations,  delusion,  and  surprises  that  we  encountered 
while  we  were  dealing  with  ISDN.  Other  key  aspects  of  this  report 
are: 


•  It  examines  the  applicability,  usability,  and  inter-operability  of 
ISDN  for  a  variety  of  present  and  future  distributed,  user  applications. 
In  order  to  make  the  findings  and  results  as  widely  applicable  as 
possible,  the  approach  taken  was  to  study  the  detailed  nature  of  the 
services  provided  at  the  various  ISDN  user  interfaces  and  compare 
these  to  the  requirements  of  user  applications. 

•  It  delineates  a  detailed  study  of  the  ISDN  user  interfaces 
examining  both  the  specifications  for  the  interface  as  well  as  for 
specific  implementations.  This  study  includes  the  effects  of  noise  and 
other  impediments  on  the  interface,  the  presence  of  improperly 
configured  terminal  equipment,  and  other  anomalies  that  might  be 
encountered  in  a  general  user  environment. 

•  In  support  of  this  project,  an  ISDN  Experimental  Facility  was 
established  to  provide  the  capability  of  developing  testing  techniques 
and  procedures  without  disrupting  the  normal  operations  of  the  public 
network  which  is  the  ultimate  target  for  the  testing.  This  report 
describes,  in  great  detail,  the  original  vision,  the  actual 
implementation,  problems  that  occurred,  and  limitations  encountered 
during  the  set  up  and  operations  of  the  experimental  facility. 

•  It  also  describes  the  specialized  test  equipment  and  test 
procedures  which  were  designed  and  developed  for  this  project.  Data 
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from  initial  tests  performed  to  obtain  quantitative  characteristics  of 
the  ISDN  services  were  reported  and  analyzed. 

•  This  report  quantifies  several  factors  in  addition  to 
performance  that  will  have  effect  on  the  utilization  of  ISDN  services. 
Although  the  research  focused  primarily  on  a  set  of  technical  issues  in 
evolving  to  ISDN,  a  number  of  other  factors,  which  are  non-technical, 
but  often  have  a  direct  impact  on  technical  issues  were  also  identified 
and  addressed. 
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Technical  Issues  in  Evolving  to 
Integrated  Services 
Digital  Networks  (ISDN) 


1.  Introduction 

It  is  our  acknowledgement  that  the  results  and  findings  from  the 
GIT’s  report1  were  extremely  instrumental  and  widely  used  in 
preparing  this  document.  Some  of  the  research  efforts  were  focused  at 
issues  in  line  with  the  Army’s  ISDN  transition  strategy  and 
requirements  that  we  gathered  through  meetings  with  various  Army  and 
DoD  organizations. 


Project  Chronology 


The  dates  for  key  milestones  during  this  contract  period  are: 


•  Contract  award 

•  Project  kickoff  meeting 

•  BellSouth  Enterprises  participation 

•  College  of  Computing/Electrical 
Engineering  move  to  AECAL 

•  Equipment  order  determined  for 
A1RMICS 


3  February  1989 
9  March  1989 
15  July 

15  September  1989 
30  September  1989 


•  Permission  to  order  equipment 
received 

•  Initial  implementation  of  S-Bus 
error  injector 

•  Informal  project  review 

•  ISDN  lines  installed 

•  Formal  project  review 


12  October  1989 

November  1989 

20  November  1989 
30  January  1990 
15  March  1990 


1The  Georgia  Institute  of  Technology  was  the  primary  contractor  for  the  project 
“Technical  Issues  in  Evolving  to  ISDN",  sponsored  by  AIRMICS.  This  work  has  been 
executed  under  contract  DAKF1 1-86-D-00I5-0022,  GIT  Project  E-21-F31  (School  of 
Electrical  Engineering)  and  G-36-615  (College  of  Computing),  during  the  period  March  3. 
1989  to  November  3.  1990. 
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2.  Scope  of  this  Report  and  Other  Project  Support 

The  primary  scope  of  this  report  is  limited  to  the  results  of  the  ISDN 
applications  research  conducted  under  the  conditions  that  these 
results  will  provide  an  opportune  foundation  to  serve  the  Army’s  needs 
towards  ISDN  transitioning.  Where  appropriate,  findings  from  other 
studies  are  referenced  and  incorporated.  All  instances  of  results  from 
other  research  or  operational  ISDN  facilities  are  acknowledged  as 
such.  A  major  and  active  supporter  of  the  current  work  is  BellSouth 
Enterprises  which  has  contributed  a  significant  amount  of  expertize  to 
this  project. 
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Technical  Issues  in  Evolving  to  ISDN 

3.  Summary  of  the  Project  Technical  Tasks 

There  were  three  sets  of  research  oriented  tasks  specified  in  the 
statement  of  work  for  this  contract 

•  The  first  set  of  tasks  required  the  development  of  techniques 
and  procedures  to  quantitatively  measure  and  evaluate  the 
performance  characteristics  of  emerging  ISDN  services. 

•  The  second  task  required  the  establishment  of  an  ISDN 
applications  research  facility. 

•  The  third  set  of  tasks  required  analysis  and  comparison  of 
potential  ISDN  services  to  existing  services. 
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4.  The  Georgia  Tech  ISDN  Experimental  Facility 

This  was  the  "second"  task  of  the  project;  however,  the  existence  of  an 
operational  experimental  facility  was  essential  to  developing  and 
verifying  the  measurement  and  evaluation  procedures  to  be  developed 
under  the  "first"  task. 


Original  Vision  for  the  Experimental  Facili 


Figure  1 


The  Georgia  Tech  ISDN  Experimental 

Facility 
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The  original  plan  for  building  an  ISDN  test  facility  was  formulated 
around  the  concept  that  generic  connectivity  would  provide  the 
solution  for  applications  testing.  It  was  felt  that  three  separate  sites 
comprised  of  equipment  of  similar  type  would  support  test  scenarios 
simulating  many  normal  environments.  It  was  envisioned  that  a  site  in 
the  School  of  Electrical  Engineering  Communications  and  Computer 
Engineering  area  (the  third  floor  of  the  College  of  Computing 
building),  a  site  in  the  AIRMICS  office  area  (located  in  the  O'Keefe 
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Building  on  the  Georgia  Tech  campus)  and  a  site  in  the  College  of 
Computing  Networking  Laboratory  would  be  interconnected  (Figure  1). 
Both  central  office  ISDN  phone  lines  and  lines  provided  by  ISDN 
central  office  simulators  connected  via  fiber  carrying  primary  rate 
ISDN  would  be  installed  allowing  testing  of  both  the  CO  LAN 
environment  and  self-deployed  post-based  LAN.  One  site,  the  College 
of  Computing  Networking  Lab,  would  be  an  experimental  node  with 
analysis  and  patching  equipment.  The  other  sites  would  be  "standard 
user"  sites  with  computers,  terminal  adapters,  and  supporting 
software  -  ISDN  control  software,  ISDN  applications  programs. 

With  the  fiber  already  in  the  ground  on  the  Georgia  Tech  campus,  the 
fiber  connectivity  was  considered  to  be  relatively  easy.  Special 
assembly  pricing  for  phone  lines  providing  ISDN  service  were 
established  by  Southern  Bell,  and  ordering  and  installation  were 
begun.  Equipment  was  ordered  to  provide  the  patching  and 
connectivity  at  all  sites  and  ISDN  protocol  analysis  gear  was  borrowed 
from  BellSouth.  As  equipment  arrived,  wiring  was  installed  and 
connections  were  completed.  There  were  some  problems  with  the 
installation  of  the  equipment  that  were  unexpected.  These  are 
discussed  below. 

One  major  purpose  of  the  experimental  facility  was  to  permit  inter¬ 
operability  testing  of  terminal  adapter  cards  and  other  terminal 
equipment  from  various  different  vendors.  Applications  were  chosen 
that  would  represent  a  cross  section  of  what  is  needed  in  the  office 
environment  and  an  attempt  was  made  to  procure  a  version  of  these 
applications  that  would  run  in  the  ISDN  environment.  Some  of  the 
application  areas  were  word  processing,  screen  sharing,  voice  call 
management,  and  shared  file  serving. 

Projected  equipment  on  each  node  consisted  of  several  PC/AT  class 
machines,  Apple /Macintosh  computers,  terminal  adapters  (both  PC 
add-in  cards  and  stand-alone);  and,  if  possible,  some  type  of 
monitoring  device.  Two  sites  were  to  include  Teleos  Central  Office 
Simulators  which  simulate  the  ISDN  service  provided  by  AT&T  5ESS 
equipment.  Since  the  "real"  ISDN  lines  obtained  from  Southern  Bell 
were  serviced  by  a  Northern  Telecom  DMS-100  Central  Office,  there 
was  now  a  capability  to  hook-up  and  install  any  ISDN  terminal 
equipment  or  terminal  adapters  regardless  of  which  form  of  signalling 
it  implemented  —  stimulus  signaling  on  the  DMS- 1 00  or  functional 
signaling  being  used  on  the  5ESS. 

The  original  goal  and  plan  were  to  have  a  test  facility  up  and  running 
within  six  months.  This  experimental  facility  was  to  contain 
sufficiently  diverse  equipment  and  applications  software  to  be  able  to 
emulate  the  generic  environment  envisioned  to  be  supported  by  ISDN- 
type  services. 
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Planned  Connectivity 

As  was  stated  earlier,  the  original  ISDN  network  was  to  consist  of  two 
separate  and  distinct  parts:  that  connected  by  the  public  central  office 
and  that  connected  by  the  customer  owned  PBX  (simulation).  It  was 
envisioned  that  eventually  (when  equipment  became  available  to  do  so) 
either  or  both  of  these  parts  would  be  interconnected  using  the 
Georgia  Tech  campus-wide  ethemet  network.  Three  sites  were 
identified  for  placing  equipment.  These  were  the  College  of 
Computing  Networking  Laboratory,  the  Electrical  Engineering 
computer  cluster  (the  AT&T  laboratory),  and  the  AIRMICS*  Research 
&  Development  Lab  in  the  O'Keefe  building  on  the  Georgia  Tech 
campus.  The  Networking  Lab  in  the  College  of  Computing  building 
was  to  be  the  major  experimental  site  housing  test  and  patching 
equipment  as  well  as  computers  for  running  applications.  The  other 
two  sites  were  primarily  for  simulating  the  office  environment  in 
which  ISDN  was  envisioned  to  be  used.  BellSouth  was  offered  the 
opportunity  to  participate  as  a  functioning  node  and  some  work  has 
been  done  toward  that  end  although  the  physical  connectivity  via  the 
central  office  would  be  the  only  possibility  as  fiber  is  not  yet  available 
from  the  Georgia  Tech  campus  to  the  BellSouth  building. 

Each  site  was  originally  planned  to  have  several  different  vendor's 
ISDN  PC  terminal  adapters  for  use  in  several  different  machines 
including  IBM  PC/ATs  and  PS2s  and  Apple  Macintoshes.  The 
AIRMICS  node  had  some  IBM  PC/ATs  and  MacIIs.  The  Networking  lab 
already  contained  several  ATs  and  procured  two  PS2/model  80  IBM 
workstations.  Apple  MacIIs  were  also  already  available  on  a  limited 
basis  in  the  Lab.  The  EE  node  consisted  of  AT&T  6386  machines 
which  were  AT  compatible.  A  Teleos  ASK200  central  office  simulator 
providing  4  basic  rate  and  1  primary  rate  lines  was  ordered  for  the 
Networking  lab  and  the  AIRMICS  lab.  EE  was  to  utilize  only  the 
Central  Office  Northern  Telecom  lines. 

In  summary,  the  AIRMICS  central  office  simulator  was  to  be 
connected  to  the  College  of  Computing  Networking  Lab  central  office 
simulator  utilizing  optical  fiber  and  all  three  sites  (Networking  Lab, 
AIRMICS,  and  EE)  would  be  connected  in  star-fashion  using  the  "real" 
ISDN  central  office  lines  through  the  central  office  at  Courtland 
Street,  Atlanta.  This  would  allow  the  study  of  both  generalized  ISDN 
connectivity  and  post,  private  exchange  ISDN  service. 


Implementation  of  the  Initial  Experimental  Facility 

The  following  activities  were  undertaken  during  the  establishment  of 
the  ISDN  laboratories  at  AIRMICS  and  at  the  GIT  College  of 
Computing. 

•  Identify  hardware  and  software  required 

•  Identify  potential  products  and  vendors 


Page  9 


Technical  Issues  in  Evolving  to  ISDN  Final  Report 

•  Obtain  products 

•  Check-out  products 

•  Interconnect  AIRMICS,  College  of  Computing,  and  EE 

•  Obtain  ISDN  lines  to  Southern  Bell  switch 

Connectivity  Actually  Established 

Ten  ISDN  BRI  lines  were  ordered  from  Southern  Bell  with  funding 
from  BellSouth  Enterprises.  Two  of  these  lines  were  to  be  delivered 
to  the  AIRMICS  lab,  two  were  to  be  delivered  to  the  EE  lab  and  the 
other  six  were  to  be  distributed  into  the  Networking  lab  and 
surrounding  offices  for  use  in  a  real  environment.  Patching  was  set  up 
in  the  data  closet  outside  the  Networking  lab  that  allowed  moving  of 
the  lines  as  needed  to  any  point  in  the  Networking  lab.  More  patching 
was  set  up  inside  the  lab  itself  for  patching  monitors  and  computers 
together  and  into  variously  configured  lines.  It  was  envisioned  that 
several  different  configurations  of  lines  would  be  necessary  for 
complete  testing:  three  of  the  lines  were  ordered  with  B  channel 
packet  switching  available  and  the  rest  were  configured  with  B 
channel  circuit  only. 

For  terminal  adapters,  several  companies  were  approached.  AMD, 
Hayes  and  Northern  Telecom  were  the  initial  providers  of  terminal 
adapter  cards  for  PC/AT  class  machines.  Teleos  and  Vadis  terminal 
adapters  were  later  purchased  since  they  also  provided  a  more  clearly 
defined  application  programming  environment  for  different  existing 
applications,  although  this  did  not  solve  the  problem.  Teleos, 

Northern,  and  Vadis  provided  call  manager  software  which  was  useful 
in  recording  logs  of  phone  calls  and  provided  a  directory  for  automatic 
call  placement.  Vadis  also  provided  electronic  mail  delivery  and 
screen  sharing.  Northern  used  the  Microsoft  Network  interface  which 
can  utilize  Word  Perfect  to  work  across  the  ISDN  through  a  screen 
sharing  package.  Teleos  provided  the  easiest  interface  to  the 
programmer  and  thus  was  the  platform  of  choice  for  doing  in  house 
programming  of  test  tools.  Also,  others  in  academia  were  using  the 
Teleos  card  and  we  were  able  to  procure  some  third  party  software 
which  was  written  to  run  on  this  platform. 

Since  there  was  no  available  ISDN  card  for  the  Macintosh  computer, 
an  external  terminal  adapter  was  necessaiy.  AT&T  7506  ISDN 
telephone  sets  were  used  to  provide  this  function  in  conjunction  with 
software  provided  by  Newbridge.  This  software  allows  sharing  of  files 
between  IBM  PCs  and  MacIIs  by  interfacing  through  the  host 
computer's  serial  ports  to  the  EIA232  interface  on  the  phone  sets. 

This  link  was  limited  to  about  19.2  Kbits  per  second  due  to  the  nature 
of  the  host  serial  ports. 
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ISDN  Wiring  and  Distribution 

As  was  mentioned  earlier,  there  are  several  different  standards  emerging 
for  ISDN  premises  wiring  distribution.  No  one  has  gained  a  firm  hold  on 
the  industry  so  there  is  still  some  ambiguity  in  what  wiring  and 
connectors  should  be  used.  BellSouth  is  standardizing  on  the  RJ45 
connector  for  both  S/T  and  U  interface  connections.  But  Northern  is  still 
making  phones  which  use  the  RJ 1 1  connector.  There  are  other 
problems  as  well.  Harmonicas,  which  convert  a  50  pin  phone  connector 
into  six  RJ45  connectors,  have  different  internal  wiring  standards.  This 
is  confusing  and  there  is  no  set  standard  as  to  which  of  these  should  be 
used  in  general.  Cables  may  be  made  straight  or  rolled.  These  terms 
refer  to  the  way  the  color  code  is  followed  in  crimping  the  RJ45 
connectors  on  the  ends  of  the  8  wire  cabling  that  is  used  for  ISDN 
connections.  If  both  of  the  connectors  have  the  same  color  code  when 
looked  at  side  by  side,  they  are  considered  straight.  If  not,  they  are 
considered  rolled.  This  could  be  thought  of  as  reversing  the  polarity  of 
the  pairs  in  the  cable  since  the  wires  are  paired  starting  with  the  inner 
two  and  moving  outward.  But  then  this  standard  is  also  not  universally 
followed.  The  rules  and  tricks  of  connecting  ISDN  devices  together  must 
now  be  learned  on  a  per  manufacturer  basis  with  help  from  their 
installers.  The  hope  is  that  someday,  a  general  document  will  be  available 
which  will  permit  someone  with  general  telephone  knowledge  to  be  able 
to  connect  any  ISDN  device. 

Generally,  ISDN  wiring  could  be  planned  exactly  like  standard  POTS 
wiring  with  one  exception:  consideration  of  the  placement  of  the  NT1, 
the  Network  Termination  (NT)  device  which  terminates  at  the  "U" 
interface  and  creates  the  S/T  passive  bus  interface.  The  NT1  requires 
power  and  may  in  turn  provide  power  to  the  Terminal  Equipment  that  it 
services  over  the  8  wire  cables  that  are  used  to  connect  up  to  eight 
terminal  devices  to  the  NT1.  This  means  that  if  the  power  to  the  NT1 
goes  out,  the  NT1,  the  Terminal  devices  will  not  operate,  and  thus  all 
phone  service  disappears.  This  may  be  a  real  problem  since  the  phone 
companies  in  the  US  do  not  plan  to  furnish  power  to  the  NT1  over  the  U 
interface.  The  consideration  of  the  placement  of  the  NTl’s  must  take 
into  account  whether  this  phone  service  outage  will  be  acceptable  or  not 
and  if  not,  some  sort  of  uninterruptive  power  supply  must  be  used  and 
all  NTls  located  near  this  device.  Otherwise  it  may  be  that  the  NTls 
may  be  distributed  to  the  offices  where  the  ISDN  services  will  be 
terminated  and  powered  from  receptacles  in  the  office.  Since  the  U 
interface  is  two  wire  and  the  S/T  interface  is  four  wire  some  cost  savings 
may  be  had  by  co-locating  the  NT  and  TE.  But  this  must  be  considered 
carefully. 

ISDN  over  the  Campus  Fiber  Network 

A  pair  of  the  campus  optical  fiber  was  allocated  to  carry  primary  rate 
ISDN  between  the  Teleos  Central  Office  Simulators  located  in  the 
College  of  Computing  node  and  the  AIRMICS  node  This  is  currently 
being  accomplished  by  using  a  standard  DS1  DSU/CSU  which  takes 
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the  DS1  signals  leaving  the  Teleos  Central  Office  Simulator  and 
transmits  them  over  a  fiber  connection  across  the  campus  in  a  point  to 
point  fashion. 

Fiber  is  not  a  trivial  media  to  work  with  as  connectors  must  be 
attached  by  someone  with  experience.  Also,  the  political  ramifications 
of  procuring  such  a  scarce  resource,  a  pair  of  fibers  installed  in 
conduit  underground,  are  not  negligible.  To  use  a  single  pair  of  fibers 
to  carry  1.544  megabits  per  second  when  it  could  be  carrying  10 
megabits  or  100  megabits,  is  considered  wasteful  to  some.  It  required 
much  discussion  for  the  College  of  Computing  to  gain  permission  to 
use  a  pair  of  multimode  fibers  for  this  project  though  it  was  assumed 
to  be  of  no  consequence  when  the  task  was  begun. 

General  Expectations  and  Disappointments 

As  was  discovered  after  the  installation  process  for  the  test  facility  was 
begun,  the  level  of  expectation  for  the  setting  up  of  the  test  bed  was 
outside  the  bounds  of  reality.  It  was  expected  that  both  Northern 
Telecom  and  AT&T  equipment  would  be  supported  by  all  vendors. 

This  proved  not  to  be  the  case  —  vendors  initially  supported  only  one 
or  the  other.  It  was  expected  that  various  pieces  of  equipment  from 
different  vendors  would  interoperate  with  other  vendors’  equipment. 
This  also  was  a  false  expectation  similar  to  the  one  that  was  prevalent 
when  Ethernet  first  started  appearing  on  computer  equipment. 

It  was  also  expected  that  if  you  could  imagine  that  ISDN  worked  in  a 
certain  way,  it  would.  The  operation  of  the  passive  bus  was  one  of 
these.  The  Northern  Telecom  Central  Office  initially  did  not  support 
dynamic  allocation  of  B  channels  to  terminal  equipment.  The  B1 
channel  was  allocated  to  the  TEI  1  device  and  B2  is  allocated  to  TEI  2 
by  the  switch.  This  prevented  all  eight  devices  on  a  fully  configured 
passive  bus  from  having  voice  access.  Only  D  channel  activity  is 
allowed  to  TEI3-TEI8.  Other  things  such  as  the  expectation  that  22 
gauge  wire  would  fit  into  standard  RJ45  connectors  caused  much 
wasted  time. 

Problems  That  Occurred  and  Limitations  Encountered 

The  problems  that  occurred  in  setting  up  the  test  facility  are  of 
general  interest  since  they  help  to  describe  experience  in  trying  to  be 
first  at  reaching  some  goal.  The  problems  can  be  divided  into  seven 
major  categories: 

•  Real  problems  with  ISDN  itself; 

•  Manufacturer  implementation  strategies; 

•  ISDN  application  software  problems; 

•  Effect  of  ISDN  on  other  application  software; 

•  Support  hardware  and  wiring; 
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•  Dynamics  of  the  ISDN  equipment  industry  and  marketplace; 

•  ISDN  line  problems. 

Problems  With  ISDN  Itself 

Real  ISDN  problems  are  those  considered  to  be  directly  caused  by  the 
ISDN  standard  itself.  Some  would  classify  the  speed  of  the  B  channel  as 
a  real  ISDN  problem  since  it  is  slow  compared  to  other  local  area  LANs 
existing  today.  This  is  not  considered  a  problem  here,  rather  an 
application  issue.  Problems  that  are  considered  in  this  category  are:  the 
lack  of  coordination  between  B  channels  in  the  basic  rate  line  making  it 
hard  to  cascade  B  channels  to  add  bandwidth;  the  multiplicity  of 
standards  for  ISDN  (CCITT,  ANSI/T1,  BELLCORE);  and  the  fact  that 
power  is  not  provided  by  the  network  (is  ISDN  a  single  line  service?). 

Manufacturers  Implementation  Strategies 

A  problem  that  surfaced  somewhat  unexpectedly  was  that  equipment 
would  usually  not  operate  with  both  the  AT&T  interface  and  the 
Northern  Telecom  interface.  This  meant  that  one  piece  of  equipment 
was  necessary  to  communicate  over  the  central  office  Northern 
Telecom  standard  ISDN  lines  and  another  was  necessary  for  the 
Teleos  provided  "AT&T  standard"  lines.  Some  software  would  work 
on  one  set  of  equipment  and  not  on  the  other.  So  the  amount  of 
equipment  necessary  to  do  applications  testing  became  much  greater 
than  expected.  It  was  apparent  that  some  software  would  have  to  be 
written  to  get  complete  connectivity  of  all  of  the  pieces  that  were 
needed  to  do  the  testing  envisioned. 

ISDN  Applications  Software  Problems 

The  major  applications  software  specific  ISDN  problem  is  the  lack  of 
application  programming  interface  specification.  This  often  led  to  a 
complete  inability  to  have  inter-operability  between  different  vendors 
implementations  of  software.  Even  where  NETBIOS  is  specified  as  the 
interface,  proprietary  additions  have  been  placed  on  top  of  NETBIOS 
for  added  functionality  which  often  causes  incompatibility  with  other 
ISDN  interfaces. 

Writing  software  for  any  of  the  equipment  (except  external  TAs)  proved 
to  be  a  great  challenge  also.  Most  companies  had  modified  an  existing 
standard  programming  interface  to  adapt  it  to  use  with  ISDN;  however, 
ISDN  provides  both  voice  and  data  capabilities.  Thus,  those  companies 
who  used  NETBIOS  had  to  add  capability.  This  meant  that  knowledge  of 
standard  NETBIOS  calls  was  not  sufficient  to  write  software  for  these 
cards.  It  was  difficult  to  find  companies  who  had  already  documented  the 
changes  to  NETBIOS  that  they  had  added  so  that  we  could  begin  writing 
code.  This  continues  to  be  a  problem.  Any  company  that  provided 
unmodified  standard  interfaces  generally  did  not  take  advantage  of  any 
new  features  that  ISDN  allowed.  This  treated  ISDN  as  a  data  pipe  and 
required  the  user  to  do  any  negotiating  of  the  channel  through  some 
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separate  interface  (such  as  the  AT  command  set  of  the  Hayes  modems  or 
the  command  set  for  the  AT&T  7506).  This  was  not  deemed  acceptable 
for  the  envisioned  environment. 

Effect  of  ISDN  on  Other  Applications  Software 

Other  application  software  problems  include  the  applications 
themselves  which  will  run  on  stand  alone  computers  but  are  very 
complex  when  used  in  conjunction  with  ISDN  interfaces. 

Configuration  is  a  major  chore  when  trying  to  bring  up  applications 
over  ISDN.  (A  somewhat  similar  condition  is  found  with  X.25 
interfaces.)  There  are  many  more  variables  to  consider  than  those 
encountered  in  "standard"  networking  software.  It  is  sometimes 
difficult  to  make  applications  work  on  top  of  services  provided  by  the 
ISDN  equipment.  There  is  also  the  problem  of  the  memory  required 
by  ISDN  device  drivers  and  Call  Managers.  There  may  be  little 
memory  left  for  other  applications. 

Support  Hardware  and  Wiring 

Support  hardware  was  a  major  stumbling  block  for  the  test  facility. 
Equipment  that  was  ordered  per  manufacturers'  specifications  and 
sales  information  did  not  work  upon  arrival.  Plugs,  jacks,  wire  sizes, 
stranded  versus  solid  wiring,  color  codes,  pairing  of  wires,  and 
connections  between  patch  panels  all  became  tedious  and  recurring 
problems  that  took  much  interaction  with  vendors  and  sales  people  to 
solve.  This  appears  to  be  a  problem  of  trying  to  use  existing  standards 
for  wiring  with  a  new  service  and  not  being  able  to  get  information 
distributed  as  to  which  standards  are  appropriate  or  specified  with 
which  parts  of  the  ISDN  specification.  There  are  apparently  different 
wiring  specifications  for  the  U  interface  than  for  the  S/T  interface. 

This  is  not  the  fault  of  vendors  or  manufacturers,  but  merely  a  lag  in 
information  distribution  and  a  lack  in  solidification  of  the  nuts  and 
bolts  of  the  standard. 

Dynamics  of  the  ISDN  Equipment  Industry  and  Marketplace 

The  type  of  industry  into  which  ISDN  was  bom  is  another  major  factor 
in  implementing  a  facility.  Much  of  the  manufacturing  sprung  up 
overnight.  But  when  the  demand  was  not  what  was  expected  some  of 
it  quickly  sank  back  into  uncertainty.  Northern  Telecom  discontinued 
its  terminal  adapter,  which  was  one  of  the  better  ones  when  used  in 
conjunction  with  Northern  Telecom  DMS100  phone  lines.  The  card 
was  intended  as  an  example  for  others  to  follow  and  to  show  what 
ISDN  services  would  provide  as  a  bootstrap  effort  for  the  industry.  It 
did  its  job  well,  but  those  that  started  using  this  card  really  had 
nothing  to  replace  it  when  it  was  removed  from  the  market.  Another 
hardware  and  software  manufacturer,  Vadis,  is  in  the  process  of  trying 
to  sell  its  hardware  line  and  remain  only  as  a  software  provider.  These 
constant  changes  and  the  resulting  uncertainties  made  it  harder  to 
obtain  service  for  these  components.  Along  with  this,  sales  force 
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turnover  made  it  very  hard  to  reach  a  state  of  continuity  and 
consistency  in  contacts  with  several  vendors. 

Shipping  delays  were  a  considerable  problem  in  this  project. 

Seemingly,  many  companies  had  product  offerings  that  were  ready  to 
ship.  But,  apparently,  most  of  these  products  were  new  and  not  in 
stock.  They  had  to  be  built  before  they  could  ship.  Teleos  required  a 
considerable  lead  time,  part  of  which  was  our  fault  for  not  having  the 
funds  up  front  for  the  purchase,  and  part  of  which  was  Teleos’  for  the 
delay  in  construction  and  shipping.  It  was  not  until  December  1989 
that  we  received  the  boxes.  Vadis  had  a  similar  problem.  We  ordered 
5  Vadis  terminal  adapters,  three  for  the  AT  platform  and  two  for  the 
PS2  platform.  The  PS2  cards  were  not  in  assembly  yet  (still 
apparently  in  beta  testing)  and  so  we  took  delivery  of  five  cards  for  ATs 
with  the  condition  that  we  would  swap  two  for  PS2  cards  when  they 
became  available.  The  cards  still  are  not  available. 

Software  upgrades  are  coming  out  fast  and  furiously  now  since  the 
standards  are  still  changing.  With  Northern’s  move  to  functional 
signalling  in  the  BCS29  and  BCS3 1  releases,  most  companies  that 
supported  Northern  are  having  to  rewrite  their  code  to  this  new 
standard.  AT&T  is  apparently  changing  some  of  their  standard  also 
and  if  BellSouth  goes  to  the  Bellcore  standard,  things  may  have  to 
change  more  still  from  the  TA  and  TE  manufacturers  standpoint. 
Software  upgrades  are  not  cheap  and  the  ongoing  changes  are  causing 
problems  with  our  connectivity.  In  moving  to  2B1Q  for  the  "U" 
interface,  most  of  our  TE  type  equipment  is  having  to  be  changed  out. 
Northern  is  doing  this  free  through  BellSouth  but  this  also  means  that 
our  phone  sets  must  be  changed.  This  is  not  a  mandatory  upgrade 
(going  to  2B1Q)  but  is  desirable  from  our  perspective.  This  change 
will  aid  in  keeping  current  with  the  industry. 

BCS31  provides  functional  signalling  from  the  Northern  switch  at  the 
central  office.  But  there  are  still  more  incompatibility  issues.  AT&T 
phone  sets  will  not  work  on  Northern  functional  lines  even  though  5ESS 
lines  provide  functional  signalling.  It  is  apparent  that  the  "standard" 
issue  is  not  going  to  be  solved  for  a  while. 

ISDN  Line  Problems 

Problems  resulted  from  being  a  early  customer  for  non-tariffed  service 
from  our  local  Bell  Operating  Company.  Being  the  first  non-internal 
customer  for  DMS100  lines  gave  us  first  hand  experience  with  the 
phasing  in  of  a  new  service.  We  helped  to  trouble  shoot  the  process  of 
ordering  lines  (with  Southern  Bell  and  the  Georgia  State  Department 
of  Administrative  Services,  the  telco  for  state  entities),  with  all  the 
associated  variables  that  needed  to  be  set  by  the  line  translations. 

Billing  was  another  area  that  provided  interesting  experiences.  Since 
ISDN  services  are  not  currently  tariffed,  negotiations  on  what  was  to 
be  charged  for  were  carried  on  by  several  groups  inside  the  phone 
company  and  ourselves.  Federal  regulations  also  had  a  part  in  this 
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confusion  and  may  need  to  be  modified  to  fit  the  new  service  provided. 
(For  example.  Federal  regulations  require  the  access  charge  to  be 
assessed  per  telephone  number  not  per  access  line.) 
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Traffic  Loader  and  Tester 

Two  types  of  connectivity  are  available  with  ISDN:  voice  and  data.  Also, 
with  data  connectivity  there  are  two  types:  circuit  switched  data  and 
packet  switched  data.  Testing  in  this  environment  requires  several 
types  of  tools.  One  tool  that  has  been  missing  in  the  data  realm  for 
some  time  is  a  device  which  will  originate  data  traffic,  send  it  out  over 
a  data  circuit  and  terminate  the  data,  keeping  complete  statistics  on 
the  delays  experienced  by  the  data  in  transit  across  the  data  circuit. 
Such  a  device  has  been  constructed  in  the  Networking  Laboratory  in 
the  College  of  Computing  and  is  called  the  Character  Timer.  A 
companion  device,  the  Packet  Timer,  has  been  constructed  and  is 
functional  although  not  to  the  degree  of  the  Character  Timer. 

It  is  important  to  understand  the  value  of  such  a  device.  In  the  voice 
world  where  circuit  switching  is  used,  delay  of  the  voice  data  is 
constant.  It  is  only  the  call  setup  time  that  varies.  Much  testing  has 
been  done  to  characterize  the  delays  involved  in  call  setup  for  voice 
switches.  But  this  has  not  been  the  case  for  packet  switches  where 
each  piece  of  data  may  experience  different  delay  as  it  traverses  the 
system.  To  understand  the  system,  one  must  understand  the 
interrelation  between  data  loading,  window  size  in  windowed 
protocols,  errors,  and  throughput.  This  is  a  non-trivial  task  even  in 
the  simplest  networks  consisting  of  two  terminals  and  one  packet 
switch.  Delay  is  directly  proportional  to  loading  and  errors  but 
inversely  proportional  to  window  size  after  some  startup  function. 
Optimizing  performance  in  such  a  system  requires  fine  tuning  and  one 
of  the  only  good  indications  of  performance  that  is  valid  is  end  to  end 
delay  of  the  data  through  the  system. 

The  Character  and  Packet  Timers  maintain  a  history  of  the  delay 
experienced  by  each  and  every  character/packet  that  was  injected  into 
the  system  and  present  that  data  as  a  histogram  on  completion  of  the 
experiment.  It  is  envisioned  that  in  the  future,  snapshots  of  the 
histogram  at  various  points  in  experiments  will  be  kept  for  later 
analysis.  In  a  well  functioning  packet  switching  system  (a  statistical 
multiplexer)  the  delay  histogram  looks  like  a  thin  Gaussian  curve 
around  some  mean.  More  loading  is  inserted  into  the  system  the 
curve  may  fatten  out  and  even  take  on  some  other  apparent  Gaussian 
overlays  on  top  of  the  original  curve.  This  is  normal  and  consistent 
with  expectations  of  statistical  systems.  But  as  the  loading  increases 
or  errors  are  introduced,  the  curve  begins  to  smear  across  the  range 
of  the  histogram  and  the  delay  has  essentially  no  mean,  becoming 
totally  random  across  some  range.  This  means  that  the  system  is 
getting  out  of  its  proper  range  of  operation.  It  is  important  to 
recognize  the  points  at  which  this  happens  so  that  network  designers 
can  allow  for  backup  and  redundancy  where  necessary.  This  has  not 
been  done  consistently  in  the  past. 
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An  important  part  of  this  research  is  to  characterize  ISDN's  packet 
switching  services  as  to  their  end  to  end  delays  under  various  loading 
and  error  conditions  so  that  these  points  of  failure  can  be  determined. 
It  is  also  necessary  to  understand  the  end  to  end  delays  and  the  delays 
associated  with  call  setup  on  of  the  circuit  switching  mode  of  ISDN 
connections.  These  results  are  all  anticipated  in  future  work. 

Three  general  capabilities  that  should  be  available  in  any  data 
communication  testing  facility  are 

•  The  generation  of  traffic  loads 

•  The  measurement  of  delivery  delay  for  traffic 

•  The  measurement  of  effective  traffic  throughput 

There  are  certainly  a  number  of  other  specific  characteristics  that 
should  be  examined  and  quantified  to  completely  describe 
performance  such  as: 

•  Call  set-up  delay 

•  Call  disconnect  delay 

•  Reliability 

•  RESET  indication  rate 

•  Protocol  robustness 

However,  these  will  be  handled  by  other  aspects  of  the  experimental 
facility. 

Functional  Requirements  for  Traffic  Loading  and  Performance  Testing 

Perhaps  the  most  important  lesson  that  has  been  learned  in  previous 
performance  testing  projects  conducted  in  the  Computer  Lab  was  that 
averages  are  an  inadequate  characterization  of  almost  all  performance 
statistics.  It  had  become  abundantly  clear  on  previous  projects  that 
averages  hid  die  interesting  or  useful  data.  It  had  been  found  that 
presenting  the  actual  observed  data  distribution,  in  the  form  of  a 
histogram  or  some  other  appropriate  graphic,  often  enables  the 
experimenter  to  gain  valuable  insight  into  the  functional  operation  and 
performance  of  the  system  under  test. 

The  general  functional  requirements  established  for  the  traffic  loading 
and  performance  testing  equipment  were  developed  during  a  number 
of  previous  performance  testing  projects. 

•  The  test  device  should  be  capable  of  generating  traffic  of  the 
required  type:  characters,  data  link  frames,  network  layer 
packets  (e.g.  X.25),  or  whatever  is  appropriate  for  the  layer 
under  examination. 

•  The  test  unit  should  be  capable  of  generating  traffic  described 
by  a  variety  of  probability  distributions  such  as:  poisson  traffic 
generation,  uniform  distribution  of  time  between  traffic  units, 
constant  time  between  traffic  units,  minimum  time  between 
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traffic  units  (traffic  is  sent  at  the  maximum  rate  possible  by  the 
load  generator),  or  have  the  time  between  traffic  units  governed 
by  flow  control  imposed  by  the  access  port  of  the  system  under 
test. 

•  The  traffic  load  generator  and  performance  tester  should  be  a 
separate  and  independent  piece  of  equipment,  i.e.  these 
functions  should  not  be  implemented  in  one  of  the  switching 
nodes  of  the  interconnection  subnetwork.  As  shown  in  Figure  2, 
this  will  permit  the  traffic  to  enter  and  leave  the  System  Under 
Test  at  different  access  points  (i.e.  ports)  and  still  be  directly 
attached  to  the  test  equipment.  This  permits  the  testing  of  the 
performance  of  paths  thru  the  System  Under  Test  (SUT)  that  do 
not  have  to  close  on  themselves  within  the  SUT.  Exiting  the  SUT 
on  the  far  side  is  quite  acceptable  and  allowable  since  the  delay  in 
the  line  connecting  the  exit  port  to  the  test  equipment  will  have 
a  fixed  delay  that  can  easily  be  measured  and  subtracted  from  all 
delivery  delay  measurements. 


•  It  is  also  desirable,  from  the  point  of  view  of  cost-effectiveness, 
that  the  test  equipment  be  capable  of  running  multiple  tests 
simultaneously.  It  is  essential  that  simultaneous  tests  be 
performed  on  many  of  the  different  types  of  systems  that  are 
tested.  Simultaneous,  parallel  tests  are  required  to  "load  down" 
the  SUT  and  to  determine  if  there  are  any  systematic 
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differences  in  the  performance  delivered  or  attainable  at 
different  parts  of  the  SUT. 

•  Some  automatic  analysis  of  the  test  data  and  graphical 
presentation  of  the  results  are  essential  functions  of  the  tester. 
Automatic  scaling  of  the  test  results  is  desirable  to  provide 
easily  interpreted  graphs.  In  accordance  with  the  requirement 
stated  above,  the  results  of  the  test  should  be  presented  as 
histograms  of  the  distribution  of  delivery  delays.  In  addition, 
the  total  throughput  achieved  for  the  period  of  the  test  should 
be  calculated  and  presented.  A  capability  to  store  test  results 
should  be  provided  so  that  the  results  of  various  test  runs  can  be 
easily  compared,  again,  graphically. 

Performance  Test  Equipment  Developed  at  Georgia  Tech 

Several  pieces  of  equipment,  which  were  designed  and  developed 
specially  for  this  project,  were  described  below. 

The  "Packet  Timer" 

The  current  work  at  Georgia  Tech  on  the  development  of  load 
generator  and  testers  is  at  the  Network  layer,  specifically  the  X.25 
Sub-layer.  This  is  an  area  in  which  performance  measurement  is  of 
high  interest  to  a  wide  variety  of  parties  including  users  as  well  as 
systems  developers;  however,  there  is  very  little  equipment  available 
to  help  them.1 

An  important  operational  requirement  for  the  Packet  Timer  is  the 
capability  to  run  simultaneous  tests  on  a  number  of  X.25  ports.  Since 
the  number  of  simultaneous  tests  desired  could  be  quite  large,  this 
created  a  subsidiary  requirement  that  the  cost  per  port  be  low.  The 
decision  was  made  to  utilize  a  multi-channel,  programmable 
communications  board  that  fit  in  the  IBM  AT  personal  computer. 

The  programmable  interface  board  has  sufficient  power  and  memory 
to  permit  the  complete  test  procedure  and  data  gathering  to  be  run  on 
the  board  requiring  no  interaction  with  the  AT  except  to  set  the  test 
parameters,  start  and  stop  the  test,  and  display  and  store  the  test 
results.  Since  the  objective  was  to  measure  the  performance,  i.e., 
throughput  and  delivery  delay,  of  the  store-and-forward  subnet,  a 
complete  implementation  of  X.25  is  not  required  —  there  is  no  need 
for  error  or  exception  handling,  special  feature  facilities,  negotiation, 
etc.  Basically,  all  that  is  required  is  the  data  transfer  portion  of  the 
X.25  procedures. 


1The  only  units  that  we  know  of  that  test  packet  performance  —  throughput  and 
delivery  delay  —  were  both  developed  In  England.  The  first.  Microflood,  was  developed 
by  British  Telecom.  Although  It  does  test  up  to  16  ports  simultaneously.  It  is  quite 
expensive  —  approximately  $100,000.  The  other  unit  developed  by  Cybernation  is 
cheaper,  approximately  $20,000;  however,  it  does  not  test  as  many  ports.  Neither  unit 
has  ever  established  a  market  In  the  U.S. 
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The  basic  capacity  of  the  interface  board  selected  is  four  synchronous 
lines.  The  board  also  has  the  capability  to  add  four  more  ports; 
however,  before  doing  that  we  must  establish  that  the  processor  can 
handle  that  many  interfaces  correctly  and  still  maintain  accurate 
timing.  Another  capacity  factor  that  must  be  evaluated  with  respect  to 
maintaining  accurate  timing  is  the  number  of  logical  channels/virtual 
circuits  that  may  be  active  simultaneously.  Obviously,  performing  a 
large  number  of  simultaneous  tests  with  one  board  is  desired,  but  only 
if  the  test  results  remain  accurate.  Another  mechanism  to  increase 
the  number  of  simultaneous  tests  is  to  utilize  multiple  boards  in  the 
same  AT  to  reduce  the  cost  per  test  port.  Since  the  AT  itself  is  not 
involved  in  any  manner  during  the  running  of  the  test  (the  board  even 
has  its  own  clock)  this  is  certainly  an  attractive  option  that  this 
approach  provides. 

The  data  reduction  and  presentation  for  the  Packet  Timer  is  the  same 
as  for  the  other  test  units  —  a  single  number  for  the  average 
throughput  per  unit  time  and  a  histogram  chart  showing  the 
distribution  of  delivery-delay  times. 

The  Current  "Character  Timer" 

The  Character  Timer  test  units  in  the  Networking  Lab  have  gone 
through  several  "generations"  of  development  —  at  least  three.  The 
motivation  in  each  redesign  was  the  utilization  of  a  new,  hopefully 
better,  implementation  platform  and  the  improvement  of  the  user 
interface  and  data  presentation. 

The  Character  Timer  has  just  recently  been  implemented  on  the  same 
platform  as  the  Packet  Timer,  a  programmable  communications 
interface  card  for  the  IBM  AT.  Obviously,  there  are  great  benefits  in 
reducing  the  number  of  different  pieces  of  test  equipment  that  must 
be  maintained  in  the  lab.  In  addition,  the  use  of  this  card  makes  it 
very  easy  to  implement  a  multi-port  tester  to  run  simultaneous  tests 
easily  and  economically.  It  is  clear  that  all  of  the  test  units  should  be 
implemented  on  the  same  platform  if  that  is  possible.  As  development 
of  such  units  continues,  there  may  be  further  changes  in  the  host 
platform  utilized;  however,  the  basic  concept,  and  even  many  of  the 
details,  will  remain  unchanged. 


Protocol  Monitoring  and  Analysis 

Monitoring  of  the  ISDN  protocols  was  necessary  for  several  reasons.  It 
was  at  times  necessary  to  monitor  the  ISDN  lines  to  locate  problems 
when  trying  to  connect  different  vendors'  equipment  together.  Also, 
with  the  large  number  of  sometimes  confusing  parameters  necessary 
to  be  set  for  configuring  an  ISDN  TA,  mistakes  were  sometimes  made 
which  required  monitoring  the  line  to  find.  There  was  a  definite 
learning  curve  involved  in  becoming  adept  at  connecting  and  running 
these  devices  and  that  curve  was  shortened  by  having  realtime 
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monitors.  It  cannot  be  overstated  that  startup  functions  in  any  field 
have  a  break  in  period  that  requires  users  to  take  an  active  part  in  the 
analysis  and  configuration  of  components.  This  will  be  a  challenge  for 
most  office  environments  for  the  next  few  years  since  most  of  these 
groups  do  not  expect  to  have  to  keep  technical  staff  on  hand  to 
troubleshoot  low  level  problems. 

The  original  concept  was  that  the  monitoring  of  the  ISDN  protocols 
and  their  analysis  under  operating  conditions  could  be  performed 
utilizing  commercially-available  ISDN  protocol  analyzers  which  were 
beginning  to  appear  on  the  market.  In  general,  this  turned  out  to  be  a 
suitable  assumption;  however,  it  was  quickly  learned  that  not  all  ISDN 
protocol  analyzers  are  "equal".  Further,  this  particular  type  of  protocol 
analyzer  was  still  being  developed  and/or  refined  by  nearly  all  of  the 
existing  suppliers,  and  the  capabilities  of  the  various  analyzers  were 
not  fixed  nor  common  across  the  industry. 

A  Tekelec  Chameleon  32  has  been  furnished  on  temporary  loan  by 
BellSouth  Services  Science  and  Technology  for  use  in  the  Networking 
lab.  This  device  provides  excellent  breakout  of  all  layers  of  ISDN 
protocols  and  a  history  mechanism  that  allows  saving  to  disk  files  of 
large  amounts  of  data  for  later  display.  It  will  act  as  both  monitor  and 
simulator  for  apparently  any  configuration  of  ISDN  equipment  and  both 
AT&T  and  Northern  Telecom  equipment.  There  were  several  times 
that  problems  could  not  have  been  solved,  or  at  least  not  as  readily, 
without  this  piece  of  equipment. 

The  Teleos  ASK200  has  some  built-in  monitoring  and  analysis  features 
that  make  it  usable  as  an  ISDN  monitor.  It  will  show  activity  on  the 
line  and  a  display  of  the  bit  fields  in  the  ISDN  frames  being  exchanged 
across  lines  connected  the  ASK200. 


Controlled  Error  Injector  for  the  ISDN  S-Bus 

It  was  felt  at  the  beginning  of  this  task  that  some  means  of  injecting 
controlled  errors  into  ISDN  connections  would  be  necessary  to  gain  a 
full  understanding  of  the  protocols  involved  and  the  interactions 
between  the  layers  that  ISDN  provides.  Random  errors,  which  one 
would  normally  expect  to  see,  would,  in  general,  only  succeed  in 
causing  the  link  to  be  lost  and  so  only  adding  delay  as  the  link  was 
reestablished.  Controlled  errors  could  instead  be  used  to  analyze  the 
protocols  and  see  where  problems  may  occur  in  particular 
environments.  It  may  be  that  these  environments  will  never  exist,  but 
the  understanding  gained  by  the  analysis  is  important  to  the  goals  of 
this  project. 

One  of  the  important  research  goals  of  the  project  was  to  perform  a 
close  examination  of  the  ISDN  control  protocols,  particularly  those 
used  on  the  D-Channel  of  the  Basic  Rate  Interface,  from  the  points  of 
view  of  correctness,  performance,  fairness,  and  robustness.  Although 
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there  have  been  previous  studies  of  some  of  these  factors,  there  was 
no  work  identified  that  addressed  the  last  factor  of  robustness  with 
substantiating  experimental  work.  To  accomplish  this  work  there  is  a 
requirement  to  be  able  to  selectively  monitor  and  modify  the  bits  in 
the  various  channels  on  the  S-Bus  as  if  they  had  been  modified  by 
noise. 

The  passive  bus  configuration  is  one  place  that  error  testing  is 
envisioned  as  necessary.  What  if  all  devices  on  a  passive  bus  assume 
that  they  have  the  channel  and  begin  transmitting?  What  happens  to 
the  CO  switch?  Does  it  reconfigure  or  go  into  diagnostic  mode?  If  so 
what  is  the  delay  incurred  on  each  of  the  stations  on  the  passive  bus? 

If  the  echo  bits  in  the  frame  level  data  unit  are  manipulated  in  a 
certain  way  this  error  can  be  inserted  and  the  results  observed. 

An  initial  design  was  begun  on  an  electronic  device  which  would 
intercept  and  repeat  an  ISDN  BRI  line  such  that  signals  coming  in 
would  pass  through  with  only  minimal  delay  and  very  specific  changes. 
For  example,  if  a  random  bit  were  flipped,  the  checksum  on  the  frame 
level  data  unit  would  appear  to  be  invalid  and  thus  the  frame  would  be 
rejected.  This  would  not  allow  changes  and  errors  to  be  inserted  into 
the  packet/network  layer  for  testing  there.  So,  the  design  was 
extended  to  allow  the  addition  of  an  intelligent  monitor  on  the  line 
which  would  understand  the  framing  and  control  information  of  all 
layers  and  allow  modifications  to  packets  or  frames  and  recalculate  the 
checksum  and  reinsert  it.  This  would  preserve  the  link  layer  integrity 
while  inserting  errors  in  specific  places. 

Direct  Injection  of  Noise 

Direct  injection  of  noise  in  the  S-Bus  signal  stream  might  have 
worked;  however,  it  is  likely  that  most  noise  hits  on  the  bus  would 
corrupt  the  signal  so  much  that  the  physical  level  of  the  TE/TA  or  the 
NT1  would  force  a  complete  disconnect  and  reinitialization  process. 

To  exercise  and  test  the  error  recovery  capabilities  of  the  D-Channel 
Data  Link  Layer  Protocol,  access  procedure,  and  control  procedures 
would  require  more  selectivity  and  finesse  in  how  the  errors  are 
injected.  The  errors  must  be  injected  specifically  into  the  D-Channel 
time  slots  on  the  bus  signal  and  they  must  be  linked  so  that  the  coding 
rules  of  the  physical  layer,  modified  AMI,  were  not  violated.  The  error 
would  then  pass  the  D-Channel  Physical  Layer  and  be  presented  to  the 
D-Channel  Data  Link  Layer  as  "a  good  Physical  Layer  bit  stream." 

An  Example  Test  —  D-Channel  Access 

Having  the  capability  just  described  would  permit  the  execution  of 
some  rather  unusual  tests.  One  question  that  holds  continuing 
interest  concerns  the  D-Channel  access  control  mechanism.  The 
purpose  of  a  D-Channel  message  is  indicated  by  its  address  field 
specifically  the  SAPI  portion,  Service  Access  Point  Identifier.  The 
access  control  procedure  for  the  TE/TA's  is  that  priority  is  given  to 
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the  transmission  of  messages  with  the  lowest  address,  i.e.  SAPI  "0” 
designates  D-Channel  messages  involved  with  circuit  switching  control 
of  the  two  B-Channels.  If  there  is  conflict  with  two  TEs  or  TAs 
sending  the  same  SAPI,  then  the  tie  is  broken  by  the  TEI,  Terminal 
Equipment  Identifier,  which  is  in  the  second  octet  of  the  address  field 
and  is  never  duplicated  on  a  S-Bus.  All  of  the  bits  received  by  the  NT1 
on  the  D-Channel  from  the  TE/TAs  are  echoed  back  to  the  TE/TAs  on 
the  other  pair  of  wires  in  the  S-Bus.  A  TE/TA  attempting  to  access 
the  D-Channel  starts  to  send  its  LAPD  frame  and  listens  to  the  echo 
bits.  If  the  TE/TA  hears  an  address  lower  than  its  own,  it  immediately 
stops  transmitting  and  waits  until  later  to  attempt  access  again. 

What  do  you  suppose  would  happen  if  all  of  the  TE/TAs  attempting  to 
access  the  D-Channel  observed  that  the  "echoed  address"  was  a  higher 
number  than  their  own?  It  is  not  at  all  clear  from  the  protocol 
description  what  would  happen.  It  appears  that  the  results  might  be 
much  more  implementation  dependent  than  protocol  definition 
dependent.  In  any  event,  the  ability  to  force  the  D-Channel  bits  to  all 
"Is"  without  causing  a  disconnect  would  allow  the  results  to  be 
observed. 

This  is  just  one  example  of  the  numerous  tests  of  the  D-Channel 
operation  that  could  be  performed  utilizing  such  a  capability. 

Functional  Requirements  of  the  S-Bus  Error  Injector 

In  order  to  perform  its  functions,  the  S-Bus  Error  Injector  (Figure  3) 
must  become  an  actual  part  of  the  S-Bus  completely  intercepting  it, 
removing  original  signals,  and  transmitting  the  modified  ones.  The 
first  capability  that  the  unit  must  have  is  the  ability  to  demultiplex  the 
S-Bus  signal  into  its  component  channels  —  NT1  to  TE:  D,  D-Echo,  Bl, 
and  B2;  TE  to  NT1:  D,  Bl,  and  B2.  After  the  individual  channels  have 
been  separated,  then  errors  can  be  selectively  inserted  to  examine 
their  effect  on  the  protocols  of  the  specific  channels. 

Design  and  Implementation  of  the  S-Bus  Error  Injector 

The  initial  design  of  the  error  inserter  has  been  completed;  a  device 
has  been  constructed  which,  when  inserted  into  an  S/T  link  between 
an  NT1  and  a  TE,  will  allow  transparent  operation  of  the  TE.  The  next 
step  is  to  add  the  intelligent  processing  to  this  device  to  allow  the 
controlled  error  injection.  Neither  of  these  steps  is  trivial.  Since 
most  ISDN  chip  sets  are  VLSI,  knowing  the  schematics  of  these  chips 
is  not  necessarily  helpful  in  the  design  of  discrete  circuitry.  Several 
different  designs  were  contemplated  before  a  successful  one  was 
found.  Also  the  speed  at  which  the  intelligent  processor  must  run  to 
analyze  the  bit  stream  coming  in  at  192k  bits  per  second  in  each 
direction  is  quite  high.  This  last  part  of  the  project  is  still  under  way. 
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Figure  3 

ISDN  S-Bus  Error  Injector 


ISDN  Central  Office  Simulation 

An  important  aspect  of  the  development  of  the  testing  program  was  a 
need  to  have  an  experimental  environment  in  which  testing 
procedures  could  be  tried  out  with  no  danger  of  causing  problems  for 
others.  Of  course,  there  were  ISDN  service  lines  providing  access  to  a 
real  ISDN  central  office;  however,  it  is  easy  to  imagine  problems  that 
might  result  from  "playing"  with  a  real  switch  that  itself  was  still  under 
development  and  field  trial  to  some  extent.  It  would  certainly  not 
favorably  impress  one  of  our  major  ISDN  research  supporters,  and  the 
effects  on  the  other  "innocent"  subscribers  were  certainly 
unpredictable.  (Needless  to  say,  there  were  several  problems  with  the 
service  on  the  "real"  ISDN  lines;  and  it  was  comforting  to  say  that  the 
experiments  to  develop  testing  techniques  definitely  were  not  the 
cause  of  those  problems.)  The  answer  was  to  use  an  ISDN  central 
office  simulator  which  was  available  as  a  commercial  product. 
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Two  ASK-200  Central  Office  Simulators  were  purchased  from  Teleos, 
Inc.  of  New  Jersey.  These  simulation  units  were  described  as  having 
the  following  capabilities: 

•  Provide  Basic  Rate  Access  (BRI)  ISDN  service  lines  fully 
emulating  the  actions  of  the  AT&T  No.5ESS  central  office 
running  the  AT&T  ISDN  software,  release  5E4.2.  (Of  course, 
the  state  of  development  of  the  software  for  the  simulators  and 
the  features  that  it  supports  is  a  "moving  target"  just  as  is  the 
state  of  development  of  the  software  for  the  real  No.  5  switch.) 

•  Provide  Primary  Rate  Access  (PRI)  ISDN  lines  that  could  be 
used  to  interconnect  two  simulators. 

•  Miscellaneous  monitoring  and  control  features  added  to  the 
simulator  to  assist  in  developing  terminal  adapters,  line  cards, 
etc. 

The  experience  of  installing  the  two  simulators  was  actually  quite 
simple.  However,  there  were  a  few  problems  encountered.  It  was 
originally  assumed  that  the  Teleos  ASK200  would  allow  PBX  type 
connectivity  to  the  local  site  and  then  provide  remote  connectivity 
over  the  central  office  BRI  lines  provided  by  Southern  Bell.  This 
turned  out  not  to  be  possible.  Tlie  ASK200  will  only  communicate 
between  like  boxes  and  over  primary  rate  ISDN.  Also,  at  this  time  the 
ASK-200  would  not  support  the  Northern  Telecom  standard.  Since 
primary  rate  was  not  available,  an  alternate  approach  was  used.  DSU's 
providing  T1  type  connectivity  over  fiber  were  installed  in  the 
AIRMICS  lab  and  the  Networking  lab.  These  were  connected  using 
the  campus  fiber  which  provided  DS1  transmission  between  the  two 
labs.  These  will  be  connected  to  the  two  Teleos  ASK200’s  to  provide 
the  backbone  connectivity  between  the  two  sites. 

Status  of  the  Central  Office  Simulation 

The  two  simulators  were  installed  and  became  operational.  They  have 
operated  as  expected  both  when  connected  directly  together  while 
both  were  located  in  the  College  of  Computing  Networking  Laboratory 
and  are  expected  to  perform  as  well  when  interconnected  over  the 
DS-1  fiber  link  between  the  Networking  Laboratory  and  the  AIRMICS 
Lab. 

The  simulators  have  fulfilled  their  intended  role  of  providing  an 
isolated  ISDN  environment  in  which  there  was  total  freedom  to 
experiment. 
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6.  Project  Results 

This  section  documents  the  activities  which  took  place  under  each  of 
the  tasks  and  the  results  of  the  work  performed. 


Analysis  of  the  ISDN  Protocols 

The  task  plan  identified  the  D- channel  as  an  area  for  research  and 
performance  analysis.  A  doctoral  student  within  the  College  of  Computing 
examined  these  protocols  and  prepared  his  PhD  thesis  entitled  "Analytical 
Studies  of  D-Channel  Traffic".  This  thesis  contains  a  theoretical  analysis  of 
the  D-channel  and  its  capabilities.  The  thesis  is  summarized  in  Appendix  C 


Functional  Tests  and  Evaluation  of  ISDN  Services 

Although  this  project  was  focused  primarily  on  a  set  of  "technical 
issues"  in  evolving  to  the  ISDN,  a  number  of  other  significant  factors 
were  identified  during  the  course  of  the  project  —  some  of  these  were 
technical  while  a  number  of  these  other  factors  are  non-technical  but 
often  have  a  direct  impact  on  technical  issues.  They  are  identified  and 
discussed  here  to  emphasize  their  importance  although  the 
investigations  of  many  of  these  issues  are  far  from  complete. 

User  Acceptance  of  ISDN  Services 

In  general,  ISDN  user  acceptance  has  been  very  slow  with  the  only 
incentive  being  free  or  reduced  costs  for  ISDN  services  for  users 
currently  experimenting  with  ISDN  via  telco-sponsored  ISDN  trials. 
There  have  been  no  specific  hard  dollar  cost  savings  offered  by  ISDN 
that  would  spur  users  to  implement  this  new  technology.  An 
application  such  as  the  Visicalc  spreadsheet,  that  fostered  growth  in 
the  personal  computer  market,  has  yet  to  be  uncovered  for  the  ISDN 
market.  In  addition,  users  with  large  investments  in  their  private 
networks  or  those  with  wideband  communication  requirements  are 
not  eager  to  convert  to  ISDN.  This  slow  acceptance  of  ISDN  is 
reflected  in  the  insignificant  implementation  of  ISDN  lines  to  date.  As 
of  the  end  of  1989,  there  were  fewer  than  100,000  lines  of  ISDN  in 
service. 

Some  of  the  reasons  the  ISDN  market  has  been  slow  in  taking  off  are 
that  only  special  ISDN  tariffs  are  available,  standards  seem  to  be  a 
moving  target,  users  cannot  connect  separate  islands  of  ISDN,  and 
ISDN  CPE  equipment  is  available  but  is  not  inter-operable. 
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ISDN  Applications 

The  ISDN  Environment  for  Applications  Software 

The  applications  software  environment  provided  by  ISDN  connectivity 
is  certainly  no  worse  than  that  provided  by  POTS.  The  lack  of  the 
analog  conversion  and  modulation/demodulation  necessary  seems  to 
decrease  the  errors  experienced  over  standard  modem  provided 
connectivity.  But,  in  this  project  connectivity  has  been  established 
only  over  a  single  CO. 

Those  applications  which  were  designed  with  ISDN  in  mind,  providing 
calling  line  ID  and  multiple  channel  utility,  are  perceived  to  be  more 
useful  than  any  existing  counterpart  over  standard  phone  service.  This 
brings  the  service  provided  by  the  phone  company  one  step  closer  to  that 
service  provided  by  local  area  networks. 

ISDN  Applications  Examined  by  This  Project 

A  number  of  applications  utilizing  ISDN  services  were  examined  during 
this  project.  Some  of  these  examinations  were  in  the  form  of  extended 
demonstrations  while  others  were  actually  utilized  by  project  team 
members  during  the  project. 

Word  Perfect  running  over  the  Microsoft  Networks  provided 
over  the  Northern  Telecom  ISDN  card 

ISDN  call  managers  running  on  Northern  Telecom  cards,  Vadis 
cards,  and  Teleos  cards 

Video  conferencing  equipment  provided  by  PictureTel 

Screen  sharing  software  provided  by  Vadis  and  Northern 
Telecom 

Electronic  mail  provided  by  Vadis 

Disk  sharing  software  provided  by  Newbridge  over  PCs  and 
Macs 

Disk  sharing  inherent  in  the  use  of  the  redirector  provided  by 
the  Vadis/Novel  combination 

IP  over  ISDN  provided  as  experimental  software  by  Doiy  Leifer  of 
the  University  of  Michigan  in  conjunction  with  equipment  and 
software  from  Teleos  and  Rockwell/CMC.  This  included  telnet, 
ftp,  rlogin,  ping,  and  other  standard  network  utilities  from  the 
UNIX  suite. 

ISDN  protocol  analysis  provided  by  Tekelec  through  BellSouth 
Science  and  Technology. 
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Lack  of  A  Standard  ISDN  API 

As  was  previously  mentioned,  the  one  greatest  stumbling  block  to 
applications  testing  was  the  lack  of  a  ubiquitous  interface  for  programs 
running  on  the  ISDN  hardware  environment.  Even  the  platform 
provided  by  Vadis,  which  includes  COMM  interface,  REDIRECTOR, 
NETBIOS  (extended),  and  a  hardware  interface,  could  not  fit  all 
applications  directly  since  there  is  the  need  to  dial  up  from  one  site  to 
another  to  gain  connectivity  over  ISDN  and  standard  applications 
(those  not  designed  to  go  over  a  network)  do  not  have  provision  for 
this.  Other  network  applications  assume  certain  tools  at  their  disposal 
including  address  and  name  resolution,  dynamic  address  assignment, 
and  broadcast  facilities.  No  address  resolution  is  provided  and  very 
little  is  done  to  allow  automatic  timing  out  of  connections  when  idle. 
Applications  programming  interface  standards  are  the  single  greatest 
need  in  the  ISDN  industry  today. 

What  is  an  "API"? 

An  application  program  interface  (API)  is  a  means  to  clearly  divide  the 
responsibilities  and  actions  required  in  providing  and  utilizing  a 
specific  set  of  services.  The  standardization  of  an  API  provides  the 
capability  to  develop  software  modules  that  are  usable  on  multiple 
platforms  with  different  implementations  of  the  server  module. 

A  typical  API  is  an  interface  between  two  software  modules  —  the 
client  which  accesses  the  services  of  the  server.  (Figure  4)  The  client 
requests  services  by  invoking  subroutines  or  procedure  calls  which  the 
server  executes.  Therefore,  a  typical  API  is  dependent  on  a  particular 
language  for  its  detailed  definition  since  that  would  include  the  exact 
syntax  (formats,  etc.)  of  the  procedure  calls  and  replies.  It  should  be 
noted  that  the  model  shown  in  Figure  4  can  be  recursive,  i.e.  the 
"client"  utilizing  a  particular  "server"  may  itself  be  a  "server"  for 
another  "client." 

What  ISDN  Applications  are  Missing 

As  the  project  progressed  it  became  clear  that  there  were  a  number  of 
"applications  software  capabilities"  that  would  be  of  high  value  in  an 
ISDN  environment;  however,  they  are  not  yet  available,  or  those 
versions  that  are  available  are  not  totally  satisfactory. 

An  Effective  ISDN  Call  Manager 

Computer-Based  Telephony 

"Groupware" 

On-Line  Discussions 

Collaborative  On-Line  Document  Preparation 
Multimedia  Applications 


Page  29 


Technical  Issues  in  Evolving  to  ISDN 


Final  Report 


Figure  4 

A  Conceptual  Model  of  an  API 
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System  Response  to  Error  Conditions 

What  is  being  referred  to  here  is  a  functional  error  not  a  transmission 
error  such  as  caused  by  noise.  An  example  will  clarify  the  difference. 

What  happens  if  two  TEls  (ISDN  terminals)  are  assigned  the  same  TEI 
(terminal  equipment  identifier),  perhaps  by  switch  settings  or 
configuration  parameters,  and  then  attached  to  the  same  S-Bus.  When 
this  was  done  it  was  observed  that  the  CO  switch  removed  the  line 
from  service  and  performed  local  line  diagnostics  for  about  fifteen 
minutes  before  reinstating  service  on  this  line.  It  was  also  observed 
that  connecting  two  devices  to  a  single  BRI  with  two  different  TEIs 
can  be  unpredictable  as  one  may  not  be  recognized  if  added  much 
after  the  first  one  is  connected.  Neither  one  of  these  has  yet  been 
rigorously  tested. 

Use  of  Multiple  B-Channels 

The  PictureTel  video  conferencing  equipment  demonstrated  another 
factor  in  using  ISDN  which  is  different  from  standard  POTS.  The 
provision  of  multiple  B  channels  over  a  single  copper  line  leads  one  to 
believe  that  using  both  of  these  B  channels  to  double  the  effective 
bandwidth  should  be  easy.  This  is  not  the  case.  There  is  no  guarantee 
from  service  providers  that  the  B  channels  will  take  the  same  path 
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through  the  network  and  so  may  have  different  delays  end  to  end. 
PictureTel  has  solved  this  problem  by  inserting  delay  into  their  system 
which  allows  resynchronizing  the  B  channels  at  the  destination,  but 
with  the  cost  of  having  a  noticeable  delay  in  conversations  held  over 
their  systems.  The  system  still  performs  very  well  but  this  added 
problem  needs  to  be  solved  in  the  future. 

LAN-to-ISDN  Bridging 

The  need  to  study  and  experiment  with  LAN-to-ISDN  bridging 
capability  was  identified  within  the  statement  of  work  and  the  task 
plan  for  this  contract.  There  are  two  aspects  to  the  LAN/ISDN 
bridging  problem.  One  was  to  identify  existing  or  newly  marketed 
equipment  that  was  available  that  would  provide  connectivity  between 
stations  on  the  ISDN  and  stations  on  other  LAN  technologies.  Another 
was  to  address  some  of  the  problems  that  exist  in  connecting  standard 
LAN  technology  over  ISDN.  Both  of  these  have  been  examined  to  some 
extent  and  are  discussed  below. 

Existing  equipment  was  of  two  types:  that  which  treats  ISDN  as  just 
another  leased  line  providing  56k  or  64k  bits  per  second  connectivity, 
and  that  which  utilizes  the  dial  up  capability  of  ISDN  to  provide 
dynamic  bandwidth  increases  to  a  connection  between  LANS.  There 
are  several  bridge  manufacturers  who  are  currently  providing  the  first, 
Vitalink  and  others,  by  exchanging  the  standard  56k  data  set  for  an 
ISDN  external  terminal  adapter.  This  essentially  requires  no  change 
to  the  existing  equipment  and  will  work  as  well  or  better  than  the 
previous  technology.  The  second  type  of  equipment  is  just  beginning 
to  appear.  There  is  apparently  only  one  manufacturer  claiming  to 
provide  dynamic  bandwidth  allocation  for  bridging  by  using  multiple 
ISDN  channels:  Teleos.  Teleos,  in  conjunction  with  IBM  is  now 
offering  the  ability  to  connect  IBM  token  ring  networks  together  using 
their  ASK  platform  with  new  software  and  a  token  ring  VME  bus  card. 
Their  claim  is  that  as  more  bandwidth  is  needed  for  traffic  between 
the  two  token  ring  networks,  it  is  provided  via  other  ISDN  channels. 

As  the  need  disappears,  it  is  tom  down.  Performance  data  for  this 
system  is  not  yet  available.  The  term  "Just  in  Time"  networking  is 
used  to  describe  this  process,  the  term  being  taken  from  the 
manufacturing  concept  where  parts  are  delivered  "just  in  time"  to  be 
used  by  manufacturing. 

It  was  felt  that  there  were  certain  problems  that  must  be  solved  before 
the  complete  integration  of  ISDN  into  the  LAN  environment  could  be 
considered  complete.  The  Internet  is  considered  the  most  functional 
interconnection  of  LANs  in  the  world  and  thus  was  used  as  a  model  of 
what  real  interconnection  should  be.  The  example  is  that  distributed 
services  should  run  on  the  network  and  be  accessible  to  all  LANs:  e.g. 
name  service  and  internet  mail  delivery.  This  is  not  currently  possible 
using  ISDN  as  a  LAN  interconnection  means,  at  least  not  in  the  general 
sense.  Work  is  being  done  to  more  fully  identify  the  issues  involved 
and  scope  out  some  possible  solutions.  For  this  reason  a  co-project 
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was  begun  to  build  an  ISDN  adapter  interface  card  for  the  NeXT 
computer  at  the  College  of  Computing  of  GIT.  This  computer  provides 
a  UNIX  platform  which  provides  applications  interfacing  to  the 
existing  Internet  services.  The  NeXT  platform  also  provides  an 
impressive  user  interface  builder  which  allows  next  to  no  time  to  be 
dedicated  to  writing  code  for  this  purpose.  The  computer’s  high 
speed  also  makes  it  suitable  for  an  ISDN  to  ethemet  router  in  keeping 
with  the  Internet  style  of  connection.  The  hardware  development  for 
this  task  is  nearing  completion  and  software  design  has  begun. 

Quantitative  Testing 

The  usability  of  any  data  communications  service  is  the  result  of  the 
combination  of  functional  capabilities  provided  and  quantitative 
performance  provided.  The  observation  and  evaluation  of  the  former 
is  relatively  easy  —  "Does  the  system  do  'X-Y-Z'  under  all  conditions?" 
On  the  other  hand,  quantitative  performance  testing  presents  a 
number  of  problems  and  challenges.  The  most  common  problem 
encountered,  not  just  with  the  ISDN  services,  is  the  lack  of  tools  to 
assist  in  making  these  measurements.  In  this  project  this  was 
addressed  by  a  specific  task  to  develop  instrumentation  for  the 
experimental.  This  task  was  discussed  above. 

Initial  Plans  for  Quantitative  Testing 

It  was  recognized  early  in  the  project  that  a  number  of  quantitative 
tests  would  be  required  in  a  complete  study  of  the  ISDN-user  interface 
services.  Some  of  these  are  listed  below. 

•  Te^ts  of  call  setup  time  on  the  ISDN  CO  switch. 

•  Tests  of  the  CO  ISDN  packet  handler 

•  Tests  of  D  channel  data  carrying  ability 

•  Measurement  of  delay  on  D  and  B  channel  packet  data 

•  Error  injection  into  BRI  service  to  test  CO  switch  and  packet 
handler 

Performance  Testing  in  the  ISDN  Environment 

The  testing  facility  was  utilized  to  conduct  performance  testing  on  the 
ISDN.  There  were  several  tests  that  were  attempted;  however,  valid 
results  were  obtained  from  only  one  set  of  tests. 

General 

The  ISDN  B  and  D  channels  provide  basically  three  modes  of 
information  exchange:  packet  information  exchange  over  the  D 
channel  using  an  asynchronous  PAD  function  provided  by  an  external 
adapter,  packet  information  exchange  over  a  B  channel  between  an 
adapter  on  the  ISDN  line  and  the  packet  handler/packet  switch  in  the 
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Central  office,  and  synchronous,  bit-oriented  data  over  a  circuit- 
switched  B  channel. 

It  is  obvious  that  the  synchronous,  bit-oriented  data  over  the  B  channel 
circuit  should  perform  exactly  as  a  modem  since  there  is  buffering  in 
the  circuit.  The  only  results  possible  from  this  testing  would  be  the 
single  delay  value  that  all  data  would  incur  as  it  traveled  to  the  central 
office  and  back.  It  is  expected  that  this  delay  value  would  be  small 
although  it  was  not  tested  in  this  project.  In  general,  modems  add 
delay  in  the  neighborhood  of  12  to  20  milliseconds  for  local  calls  with 
increasing  delay  related  to  the  distance  between  the  modems.  This 
same  or  lower  expectations  should  apply  for  the  B  channel  circuit- 
switched  service. 

Performance  Testing  Procedures 

B- channel  packet  switching  was  not  tested  since  equipment  was  not 
available  which  would  complete  a  packet  call  to  the  packet  switch  in 
the  central  office.  B-packet  lines  were  available;  however,  the  available 
equipment  (Infotron,  provided  by  Southern  Bell)  was  never  brought 
into  proper  operation  to  achieve  packet  connections  to  other  packet 
lines  in  the  lab. 

D- channel  packet  switching  was  tested  and  consistent  results  were 
obtained.  The  D  channel  operates  in  the  packet  mode  for  everything. 
Control  packets  are  exchanged  for  call  setup  and  idle  circuit 
management.  The  D  channel  is  multiplexed  between  all  eight  possible 
stations  on  the  passive  bus.  This  implies  that  the  D  channel  is 
statistically  multiplexed.  Our  past  experience  with  statistically 
multiplexed  systems  has  shown  that  statistical  multiplexing  causes 
random  delays  around  some  mean  delay  time.  The  smallest  time  is 
usually  fixed;  however,  the  maximum  delays  depend  on  loading  into 
the  system.  These  characteristics  were  confirmed  by  our  testing  of  the 
ISDN  D  channel  in  the  lab. 

Performance  Testing  Results 

Figure  5  is  typical  of  the  results  obtained  from  injecting  asychnronous 
character  traffic  into  a  D  channel  PAD  (packet  assembler 
disassembler)  produced  by  Infotron.  This  device  is  a  stand  alone  ISDN 
Terminal  Adapter  which  operates  in  the  PAD  mode  on  the  D  channel 
and  B  channels.  It  has  two  ports  of  which  one  was  used  on  each  end. 
The  character  timer  described  elsewhere  in  this  document  was 
connected  with  its  output  side  to  one  Infotron  PAD  and  its  input  to  the 
other.  The  circuit  was  set  up  externally  and  the  experiments  were 
begun  using  different  character  loading  rates  for  different  trials.  The 
PADs  were  set  up  as  follows;  each  character  caused  a  single  packet  to 
be  assembled  and  transmitted,  echo  was  turned  off,  flow  control  was 
disabled,  the  window  was  left  at  the  default  value  of  2  at  the  link  level. 

It  must  be  kept  in  mind  that  the  PAD  function  utilizes  X.25  which  is  a 
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Figure  5 

Character  Delivery  Delays 

Typical  Test  Results  —  Single  Test 
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layered  protocol  and  the  concatenation  of  the  link  layer  (LAP/D)  and 
the  packet  layer  (PLP)  can  cause  some  of  the  effects  that  were 
observed.  But,  in  general,  the  observations  show  that  the  asynchronous 
nature  of  the  packet  handler  is  the  main  cause  of  the  variations  in 
delay  across  the  network. 
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The  graph  has  two  axes:  the  horizontal  axis  is  time  delay  experienced 
by  characters  as  they  traverse  the  circuit  through  the  system  under 
test  and  the  vertical  axis  is  the  number  of  characters  which  incurred 
the  delay  value  represented  on  the  horizontal  axis.  Thus  where  a 
normal  curve  is  shown,  most  characters  incurred  the  mean  delay  with 
some  coming  earlier  and  some  coming  later.  Interestingly,  the 
performance  measurements  on  the  D  channel  usually  produced 
bimodal  graphs  indicating  that  several  different  factors  were 
overlapping  causing  the  delays.  As  loading  was  increased,  the  mean  of 
the  curves  always  moved  to  the  right  indicating  a  longer  delay.  This 
can  be  explained  by  the  nature  of  queueing  systems  where  characters 
and  packets  are  held  in  buffers  in  queues  until  such  tii?ie  as  they  can 
be  transmitted.  This  increases  the  delay  across  the  system.  Since  all 
curves  were  very  similar,  a  single  graph  is  reproduced  here. 

Limitations  of  the  Experimental  Setup 

Equipment  delay  must  be  noted  as  a  major  cause  of  the  large  delays 
indicated  on  Figure  5.  A  test  was  done  to  determine  the  delay  between 
sending  characters  into  a  PAD  and  getting  the  echo  back.  The  results 
show  that  20-40  ms.  of  the  delay  are  caused  by  internal  processing  in 
the  pad.  There  was  no  flow  control  available  on  the  character  timer. 
Thus  at  high  character  loading,  the  delay  results  could  not  be  assumed 
to  be  accurate.  The  ISDN  protocol  analyzer  connected  to  the  line  was 
observed  for  consistency  of  the  results;  and  when  the  character  timer 
appeared  to  be  dropping  too  many  characters,  the  results  were 
discarded.  It  was  consistently  observed  that  the  minimum  delay 
incurred  by  characters  traversing  the  ISDN  D  channel  was  about  130 
ms.  This  is  high  compared  to  other  packet  switching  systems; 
however,  a  complete  test  has  not  been  done  to  see  how  this  really 
compares  to  other  available  systems. 

Performance  Testing  Completed 

Several  performance  tests  were  performed  before  this  phase  of  the 
project  terminated. 

B-Channel  Call  Completion 

Call  completion  for  calls  local  to  one  CO  switch  is  very  quick,  less  than 
one  second.  For  non  local  calls  this  increases  to  from  5  to  30  seconds 
now.  This  is  expected  to  decrease  when  SS7  is  available  between  CO 
switches. 

B-Channel  Data  Delivery-Delay 

The  B  channel  circuit,  as  expected,  has  no  variability  in  delay.  Only 
local  CO  testing  has  been  performed. 


Page  35 


Technical  Issues  in  Evolving  to  ISDN 
D-Channel  Data 


Final  Report 


D  channel  data  was  implemented  and  tested;  however,  this  capability 
was  not  tested  with  the  full  passive  bus  configuration  nor  with  heavy 
call  setup  load  and  heavy  data  loading.  See  Figure  5  for  an  example  of 
the  results  of  a  D-Channel  test. 
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7.  Other  Factors  Affecting  the  Usability  of  ISDN  Services 

Deployment  of  ISDN  in  the  united  States 

The  deployment  of  ISDN  Services  within  the  United  States  presents 
several  challenges  and  several  economic  as  well  as  legal  obstacles.  A 
major  problem  is  funding  this  deployment  considering  both  new 
capital  costs  —  major  changes  to  central  office  hardware  and  software, 
changes  to  the  customer  distribution  subsystems,  and  changes  to  the 
customer  equipment  —  as  well  as  the  increases  in  recurring 
maintenance  and  support  costs.  How  much  more  will  the  customer  be 
willing  to  pay  for  the  "added  benefits  of  ISDN  service"? 

Even  after  the  funding  questions  have  been  resolved  another  major 
problem  still  remains  —  what  is  a  suitable  deployment  plan?  Obviously, 
the  entire  country  can  not  convert  to  ISDN  overnight.  What  phasing 
makes  sense? 

Effects  of  "Non-Universal"  Deployment  of  ISDN  Services 

Of  what  value  are  ISDN  services  if  they  are  available  only  at  your 
location  and  not  at  the  "distant  end"?  Obviously,  they  can  not  be  used 
directly.  There  have  been  proposals  for  the  introduction  of  modem 
pools  at  non-ISDN  central  offices  to  handle  the  last  mile  of  the  data 
transmission;  however,  the  implementation  of  such  a  plan  would 
require  a  large  amount  of  nationwide  coordination  and  cooperation. 
There  are  no  simple  answers  to  this  problem. 

The  comment  has  been  made  that  the  ISDN  services  could  at  least 
provide  additional  capabilities  in  your  local  area.  The  weakness  in  this 
argument  is  that  operations  at  the  "ISDN-end"  would  then  have  to 
support  two  modes  of  data  communications  operations  —  ISDN  and 
non-ISDN.  This,  of  itself,  would  probably  be  counter-productive. 

There  is  no  question  that  ISDN  services  will  not  become  truly  useful 
until  there  is  reasonably  widespread  deployment. 

Deployment  of  CCITT  Signaling  System  #7  vs  Deployment  of  ISDN 

To  date,  almost  all  of  the  ISDN  implementations  have  been  standalone 
islands  with  no  interconnections  between  remote  locations.  Part  of 
the  reason  is  that  the  local  exchange  and  long  distance  central  office 
switches  have  not  been  totally  digitized.  Besides  this,  the  telcos 
central  offices  have  not  implemented  Signaling  System  7  (SS7)  which 
is  required  in  order  to  support  ISDN  applications  between  remote 
locations.  SS7  is  the  key  element  required  for  ISDN  universal 
availability  which  will  not  be  totally  implemented  for  many  years. 
Therefore,  ISDN  will  develop  in  a  piecemeal  manner  with  major 
metropolitan  areas  first  having  ISDN  and  SS7  capabilities  with  other 
remote  areas  eventually  implementing  SS7.  Users  will  therefore 
increase  their  ISDN  applications  in  a  step-by-step  basis  until  SS7  is 
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widely  available  to  provide  universal  ISDN  services  to  connect  the 
existing  islands  of  ISDN  together. 

The  stumbling  block  in  SS7  connectivity  is  the  enormous  capital 
expense  associated  with  implementing  the  equipment  for  SS7  at  the 
telco's  central  offices.  In  addition,  the  interconnection  between  local 
exchange  companies  and  inter-exchange  companies  is  taking  place 
very  slowly.  While  competing  inter-exchange  carriers  have  managed 
to  interconnect  SS7  networks,  inter- connectivity  between  inter¬ 
exchange  and  local  exchange  carriers  remains  an  elusive  goal.  This 
connectivity  at  the  access  tandem  level  will  potentially  not  occur  until 
the  1992  time  frame.  At  the  central  office  level,  nationwide  inter- 
connectivity  probably  will  not  be  completed  until  the  end  of  this 
century.  The  local  exchange  carriers  lack  the  incentive  to  install  SS7 
and  provide  connectivity  to  inter-exchange  carriers.  In  addition,  the 
local  exchange  carriers  are  keeping  inter- exchange  carriers  in  the 
dark  regarding  local  exchange  interconnection  plans,  proposed  tariff 
formats,  rates  and  schedules. 

The  ISDN  Customer  Premises  Equipment  (CPE)  Issues 

The  issue  here  is  the  cost  of  ISDN  terminating  equipment.  It  will 
certainly  be  appreciably  higher  than  present  terminating  equipment  — 
both  voice  and  data.  If  the  deployment  is  good,  then  businesses  would 
probably  be  willing  to  pay  the  added  costs  for  the  benefits  achievable. 
However,  it  is  certainly  doubtful  that  even  a  substantial  proportion  of 
residential  subscribers  would  be  willing  to  buy  new,  more  expensive 
telephones  to  replace  those  that  they  were  only  recently  forced  to 
purchase.  A  major  impact  of  this  would  be  the  effect  on  deployment 
plans.  How  can  a  deployment  plan  work  that  is  based  only  on  business 
adoptions? 

The  Narrowband-ISDN  vs.  Broadband-ISDN  Controversy 

Narrowband-ISDN  is  the  basic  2B+D  service  —  two  circuit-switched 
channels  at  64  Kbps  each  and  one  control/data  channel  at  16  Kbps. 

The  perception  is  that  there  is  little  that  the  general  subscriber,  e.g.,  a 
residential  user,  can  get  with  this  that  can  not  be  obtained  with  the 
currently  available  services.  Hence,  there  is  little  incentive  to  pay  the 
added  costs  of  new  terminal  equipment  and  increased  monthly 
charges.  Many  feel  that  this  situation  will  present  a  major,  if  not 
complete,  barrier  to  the  deployment  of  N-ISDN. 

The  availability  of  broadband  services  (above  64-Kbps,  even  up  to 
Mbps)  would  make  it  possible  to  delivery  to  the  general  customer 
something  that  he  is  probably  willing  to  pay  extra  for  —  for  example, 
entertainment  in  the  form  of  on-demand  video.  For  this,  and  other 
reasons,  many  have  taken  the  strong  position  that  ISDN  deployment  in 
the  U.S.  must  wait  on  B-ISDN  to  be  effective. 
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Legal  Issues  Effecting  The  Deployment  of  ISDN 

Legal  issues  will  certainly  have  an  impact  on  the  deployment  of  ISDN. 
In  Europe  the  public  carriers  are  rapidly  moving  ahead  on  the 
deployment  of  ISDN  for  they  see  ISDN  as  an  opportunity  to  enter  into 
whole  new  areas  of  business  —  the  providing  of  telematic  services,  data 
base  access,  information  services,  video,  etc.,  as  contrasted  to  strictly 
telecommunication  services.  It  is  the  added  income  from  the  new 
services  that  will  provide  a  large  proportion  of  the  added  costs  of 
ISDN.  Of  course,  in  the  U.S.  the  common  carriers  are  currently 
prohibited  from  engaging  in  such  business. 

Another  legal  issue  has  been  raised  that  may  impact  some  of  the  new 
services  being  proposed  for  ISDN.  The  particular  service  currently 
being  examined  is  ANI-Automatic  Number  Identification,  and  the  legal 
questions  being  raised  have  to  do  with  privacy  issues.  That  service  is 
already  being  provided  in  pre-ISDN  systems,  and  that  is  the  cause  of 
the  present  concern.  The  ISDN  issue  is  that  several  businesses  see 
the  availability  of  ANI  as  an  extremely  attractive  feature  for  improving 
the  performance  of  handling  customer  calls.  If  legal  restrictions  are 
placed  on  ANI,  that  will  be  just  one  more  impediment  to  establishing  a 
solid  business  case  supporting  deployment. 

Full  Implementation  of  the  ISDN  Packet  Handler 

This  is  certainly  a  change  in  the  nature  of  the  issue  being  raised.  This 
is  a  technical  issue  rather  than  economic  or  legal.  There  is  not  yet 
available  a  complete  implementation  of  the  ISDN  central  office  packet 
handler.  There  are  both  implementation  problems  as  well  as 
specification  issues  that  must  be  addressed. 

The  ISDN  CO  packet  handler  is  almost  a  complete  store-and-forward 
packet  switch,  and  that  characteristic  alone  defines  a  rather  major 
implementation  task.  In  fact,  the  packet  handler  has  to  perform  a 
number  of  functions  that  a  regular  packet  switch  does  not;  and  those 
added  requirements  only  exacerbate  the  implementation  problem. 

A  further  issue  is  raised  by  the  definition  of  the  role(s)  of  the  ISDN 
Packet  Handler.  Will  it  handle  packet  data  on  the  D-Channel  only  or 
will  it  support  a  direct  connection  to  a  B-Channel  for  the  purpose  of 
handling  packet  data  on  that  channel?  Is  the  packet  handler  going  to 
serve  merely  as  a  gateway  into  already  existing  packet- switched  public 
data  networks  or  will  it  also  serve  as  a  member  of  a  new  packet 
switched  subnetwork  consisting  of  several  ISDN  Packet  Handlers 
directly  trunked  together?  To  assume  the  later  role  means  that  the 
Packet  Handler  becomes  even  more  complex  than  a  regular  packet 
switch. 
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Transition  to  and  Integration  of  ISDN  Services 

The  deployment  issues  raised  above  were  primarily  economic  ones. 
Again,  there  are  definitely  a  number  of  technical  issues  involved. 
Integrating  ISDN  services  into  the  existing  systems,  interconnecting 
the  various  systems  to  provide  reasonable  services,  and  transitioning 
to  all  ISDN  present  a  number  of  very  difficult  technical  problems  that 
must  be  solved.  It  is  beyond  the  scope  of  this  report  to  discuss  those; 
however,  the  magnitude  of  the  problem  can  be  highlighted  by  noting 
the  number  of  systems  that  must  be  integrated. 

Integrating  Interexchange  Carriers  and  Local  ISDN  Services  and 
Facilities 

Integrating  ISDN  Packet  Handling  with  the  Public  Switched 
Telephone  Networks  (PSTNs) 

Integrating  ISDN  Packet  Handling  with  the  Packet-Switched, 
Public  Data  Networks  (PSPDNs) 

Integrating  ISDN  Data  Services  with  the  Internet 

Integrating  ISDN  Services  with  Private  Networks 

Creating  an  apparently  "seamless  network"  for  voice  Services 

Creating  an  apparently  "seamless  network"  for  data  Services 


Network  Numbering  Plans 

Some  of  the  details  of  the  various  numbering  plans  are  given  in  the 
Appendix  A.  Suffice  it  to  say  in  this  paragraph  that  there  are  different 
numbering  plans  defined  for  the  present  public  switched  telephone 
networks  (PSTN),  the  present  public  data  networks  (X.25  and  X.21), 
and  the  ISDN.  The  maximum  length  of  the  address  number  is 
different  in  each  plan,  i.e.,  12,  14,  and  15  digits.  The  problem  for  the 
future  is  that  all  of  the  existing  systems  have  to  transition  to  the  ISDN 
numbering  plan.  How  to  accomplish  this  is  a  major  question  being 
examined  by  the  CCITT.  (It  should  be  noted  that  we  often  do  not  give 
numbering  plans  the  attention  they  deserve  and  require  during  the 
planning  stage  to  avoid  the  problems  that  can  appear  later.) 


Network  Management  of  "ISDN1  Private  Networks 

Network  management  is  an  aspect  of  ISDN  that  is  not  well  understood 
at  this  time.  The  understanding  of  what  the  term  network 
management  means  to  ISDN  requires  determination  of  the  network 
management  requirements  of  ISDN,  both  as  an  independent 
management  domain  and  in  relation  to  integration  of  an  ISDN  with 
other  network  technologies  and  management  domains.  Efforts 
towards  identifying  and  understanding  these  requirements  are  taking 
place  under  the  North  American  ISDN  User's  (NIU)  Forum.  There  is 
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an  ISDN  Implementor's  Workshop  (IIW)  profile  team  focused  on 
Network  Management  and  ISDN  Administration.  Their  work  is  not 
complete  at  this  time. 


Costs  of  ISDN  Services 

How  are  the  costs  for  ISDN  services  to  be  calculated?  Even  if  the  basic 
principle  of  "return  on  investment"  (ROI)  is  accepted,  and  it  generally 
is,  the  problem  is  allocation  of  the  investment  costs.  In  today's  public 
networks  the  degree  of  integration  already  present  creates  a  very 
difficult  cost  allocation  problem.  For  the  level  of  integration  that  is 
envisioned  for  ISDN,  the  issue  of  cost  allocation  becomes  that  much 
more  difficult.  The  criticality  of  this  can  be  appreciated  when  it  is 
realized  that  "cost"  should  provide  some  basis  for  the  tariff. 


Effects  of  the  "Advanced  Intelligent  Network"  IAIN) 

ISDN  is  basically  a  user  interface  to  the  services  of  the  public 
networks.  AIN  is  concerned  with  the  internal  control  and  operation  of 
those  public  networks  to  provide  the  services.  Certainly  AIN  will 
provide  essential  support  to  ISDN;  however,  the  reverse  is  not 
necessarily  true.  The  telephone  companies  are  moving  ahead  with 
AIN  somewhat  independent  of  progress  on  ISDN,  for  the  need  for 
"Intelligent  800  Service"  already  exists  and  operations  must  be 
improved  regardless  of  ISDN. 


ISDN  Networking  Systems  Design 

There  is  no  question  that  the  availability  of  ISDN  services  will  provide 
an  opportunity  for  new  design  concepts.  Many  of  the  ideas  presented 
for  "improved"  systems  merely  exploit  the  high-speed  data  capabilities 
of  64 -Kbps.  A  few  have  managed  to  utilize  the  capability  for 
simultaneous  voice  and  data  provided  by  the  two  B-Channels;  however, 
even  that  can  be  done  today  with  two  lines.  A  "true  ISDN"  application 
system  design  would  be  one  that  supported  an  application  in  a  manner 
that  can  not  be  done  with  a  combination  of  current  sendees.  An 
example  of  such  a  system  design  is  discussed  below. 

Customer  Call  Handling  Using  Specialized  ISDN  Services 

When  a  customer  call  is  received  it  is  connected  to  an  automated  voice 
response  unit  that  then  interrogates  the  caller  to  determine  some 
basic  information  such  as  caller  ID /membership  number,  caller 
location,  general  nature  of  call,  etc.  This  information  is  then  placed 
into  a  data  packet  that  is  distributed  to  the  attendant  stations  over 
their  D-Channels  utilizing  the  ISDN  Packet  Handler.  The  caller's 
information  packet  is  identified  by  the  caller's  number  which  is 
provided  by  ANI.  When  the  call  is  answered  by  a  human  attendant. 
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ANI  again  identifies  the  caller  and  permits  access  to  the  information 
packet  which  has  been  sent  to  the  attendant  station. 
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Objectives  and  Goals  nf  This  Project 

The  primary  objective  of  this  research  and  study  project  was  to 
examine  the  applicability  and  usability  of  ISDN  for  a  variety  of  present 
and  future  distributed,  user  applications.  The  approach  taken  was  not 
just  a  simple  trial  usage  test.  In  order  to  make  the  findings  and 
results  as  widely  applicable  as  possible,  the  approach  taken  was  to 
study  the  detailed  nature  of  the  services  provided  at  the  ISDN  user 
interfaces  and  compare  these  to  the  requirements  of  user  applications 
as  they  could  best  be  determined.  The  study  goals  also  included  a 
detailed  study  of  the  ISDN  user  interfaces  to  include  the  effects  of 
noise  and  other  impediments  on  the  interface  examining  both  the 
"specifications"  for  the  interface  as  well  as  for  specific 
implementations,  the  presence  of  improperly  configured  terminal 
equipment,  and  other  anomalies  that  might  be  encountered  in  a 
general  user  environment. 


Project  Accomplishments 

Establishment  of  the  ISD  f  Experimental  Facility 

The  first  and  most  critical  activity  of  the  project  was  the 
establishment  of  the  ISDN  Experimental  Facility.  This  wa.  required  to 
provide  the  test  environment  to  accomplish  the  study  tasks.  This 
facility  was  established,  although  not  to  the  extent  that  was  originally 
envisioned.  ISDN  terminal  equipment  (i.e.,  ISDN  telephones  and 
ISDN  Terminal  Adapter  Cards  for  personal  computers)  was  obtained 
and  installed;  two  ISDN  central  office  switch  simulators  were 
installed;  ten  real  ISDN  lines  were  installed  by  the  local  telephone 
company;  a  limited  amount  of  ISDN  test  equipment  was  obtained;  and 
some  ISDN  application  software  was  obtained  and  installed  on  the 
personal  computers.  Existing  test  equipment,  i.e.,  a  character  load 
generator  and  delivery  delay  timer  was  also  made  available  for  use  in 
the  experimental  facility  in  order  to  perform  the  initial  performance 
measurements.  A  number  of  technical  and  equipment  availability 
problems  were  encountered  during  the  establishment  of  this  facility. 
Although  these  had  an  adverse  effect  on  delaying  and  limiting  the  test 
program,  the  nature  and  extent  of  these  problems  are  considered  part 
of  the  findings  of  this  study  since  they  would  certainly  have  a  major 
impact  on  the  installation  and  utilization  of  ISDN  applications  by  a 
general  user. 

The  Testing  Program 

As  mentioned  above,  the  problems  in  establishing  the  test  facility  and 
the  resulting  delays  had  a  major  impact  on  the  testing  program.  The 
ability  to  perform  throughput  and  delivery  delay  tests  of  ISDN  data 
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packets  through  real  ISDN  central  office  switches  was  demonstrated 
and  initial  results  obtained.  A  large  amount  of  additional  testing  must 
be  performed  before  these  results  can  be  generalized.  The  testing  of 
the  reaction  of  the  interface  protocols  to  the  presence  of  noise  was 
not  performed  due  to  the  problems  encountered  in  designing  and 
implementing  the  S-Bus  Noise  Injector.  (Work  continues  under 
another  project  on  the  development  of  this  piece  of  test  equipment 
since  testing  the  ISDN  D-Channel  protocols  in  the  presence  of  noise  is 
considered  an  important  aspect  of  our  overall  ISDN  research 
program.) 


Factors  Effecting  the  Use  of  ISDN 
Availability  of  ISDN  Applications 

One  of  the  major  impediments  to  the  acceptance  and  utilization  of 
ISDN  communication  services  at  the  present  time  is  the  almost  total 
absence  of  ISDN  applications.  Of  course  this  can  be  a  "Catch-22"  or  a 
"chicken  and  egg"  situation  —  there  are  no  ISDN  applications  available 
because  there  is  no  market  for  them  and  there  is  no  market  because 
there  are  no  applications  to  generate  the  market  interest.  Obviously,  if 
widespread  utilization  of  ISDN  services  is  to  occur,  something  must 
break  this  circular  deadlock. 

Another  factor  that  is  affecting  the  preparation  of  ISDN  applications  is 
the  lack  of  a  standard  ISDN  API  (Application  Program  Interface)  to 
create  an  environment  in  which  ISDN  applications  could,  at  least  to 
some  degree,  be  portable  across  different  execution  platforms.  The 
development  of  a  "standard"  ISDN  API(s)  appears  to  be  a  key  factor  in 
fostering  the  growth  of  usage  in  this  area,  and  this  issue  is  being 
addressed  by  a  working  group  within  the  North  American  ISDN  User 
Group  (NIU). 

Availability  of  ISDN  Services 

A  communication  service  is  of  little  or  no  value  if  it  is  not  available  to 
provide  end-to-end  service.  It  is  difficult  to  generate  interest  in  ISDN 
services  when  they  are  being  provided  only  in  widely  separated 
geographical  islands,  and  it  is  not  at  all  clear  to  potential  users  when 
the  amount  of  geographical  coverage  will  be  improved  to  the  level 
necessary  to  make  the  services  attractive  or  even  usable. 

Market  Perception  of  ISDN 

Another  significant  factor  that  affects  the  acceptance  and  utilization  of 
ISDN  services  was  observed  during  this  study.  ISDN  has  for  the  most 
part  been  "marketed"  as  a  technology  not  as  services.  Users  are 
reacting  as  might  be  expected  in  wondering  why  they  should  be 
interested  in  a  new  technology  when  what  they  want  are  services. 
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There  is  no  question  that  an  ISDN  access  Mne  to  a  central  office  will 
cost  more  than  a  "plain  old  telephone"  (POTS)  line.  The  increases  in 
costs  will  not  only  affect  the  access  line  charges  themselves  but  also 
the  cost  of  terminal  equipment.  Statements  are  made  by  some 
telephone  company  executives  that  they  are  "willing  to  pay  1.5  times 
as  much  per  line  for  an  ISDN  central  office  as  compared  to  a  standard 
switch."  These  added  costs  must  be  recovered  from  somewhere,  and 
the  only  logical  answer  is  increased  subscriber  charges.  Although 
major  reductions  can  be  anticipated  in  the  costs  of  ISDN  terminal 
equipment,  those  devices  will  still  cost  appreciable  more  that  regular 
telephones  and  modems,  and  the  users  do  not  perceive  any  really 
important  improvements  in  the  services  that  they  obtain. 

Network  Management  and  ISDN 

Another  factor  that  is  going  to  have  a  strong  effect  on  the  use  of  ISDN 
is  the  availability  of  network  management  capabilities  for  utilization 
with  ISDN  services,  especially  when  those  services  are  being  utilized 
as  resources  in  a  private  data  network.  Network  management  is  being 
more  and  more  important  to  network  operators,  and  for  ISDN  services 
to  be  effectively  and  widely  utilized  it  must  be  supported. 


Other  Findings  of  the  Project 
Complexity  of  Service  Offering 

Although  the  ISDN  user  services  are  not  very  complex  conceptually, 
i.e.,  digital  access  to  a  variety  of  communication  services,  in  practice 
they  are.  The  complexity  is  first  encountered  when  the  initial  order  is 
placed  for  ISDN  service  —  the  customer  must  specify  the  options  and 
features  desired  and  some  technical  details;  matters  that  never 
concerned  him  before.  In  addition,  the  use  of  the  services  and  the 
detection  and  handling  of  troubles  presents  additional  technical  issues 
to  the  users  that  they  are  not  prepared  to  deal  with. 

ISDN  Development  Problems 

Any  new  technology  is  going  to  have  its  share  of  development 
problems;  however,  the  development  and  implementation  of  ISDN, 
which  really  equates  to  the  implementation  of  the  ISDN  Central  Office, 
seems  to  have  had  a  large  number  of  delays.  This  may  well  be  the 
result  of  the  problems  in  developing  packet  handling  capabilities; 
however,  these  should  certainly  have  been  anticipated  by  anyone  who 
is  at  all  familiar  with  the  development  of  similar  capabilities  in 
standalone  packet  switches. 
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Although  the  important  standards  for  ISDN  interfaces  were  published 
in  1984  and  developed  even  earlier,  there  were  still  a  number  of  open 
issues  that  required  standardization  —  network  termination  interfaces, 
testing,  control  messages,  and  many  others.  There  is  no  doubt  that 
the  absence  of  these  standards  has  had  an  adverse  effect  on  the 
development  of  ISDN  equipment  as  well  as  its  acceptance,  even  in 
concept,  by  knowledgeable  user  communities. 


What  Might  be  the  Real  Value  of  ISDN 

The  above  comments  may  paint  too  bleak  a  picture  for  the  value  of 
ISDN  services.  That  is  really  not  a  valid  assessment  of  the  situation. 
There  are  a  number  of  problems  that  must  be  overcome  in  order  to 
achieve  major  user  acceptance,  availability  of  ISDN  applications, 
simplification  of  usage,  and  widespread  deployment;  however,  ISDN 
services  do  have  something  valuable  to  offer  the  users. 

Support  for  "Unique”  Applications 

There  are  applications  that  can  only  be  implemented  using  integrated, 
high-speed  services  such  as  those  available  with  ISDN.  One  of  those 
was  examined  by  the  research  team  in  another  project,  and  the  value 
of  using  ISDN  was  quite  obvious. 

Public  Switched  Digital  Service 

ISDN  services  will  provide  a  capability  heretofore  not  available  in  the 
United  States,  switched  digital  service.  However,  even  in  this  area 
that  has  previously  been  left  unserved,  competition  to  ISDN  is  arising 
with  the  SMDS  service  offering  which  is  now  beginning  to  appear. 

LAN  Bridging 

LAN  bridging,  i.e.,  the  interconnection  of  private  local  area  networks, 
is  not  well  supported  with  the  public  networks  services  currently 
available.  There  is  no  question  that  ISDN  would  be  extremely  useful 
here;  however,  it  is  not  clear  that  this  usage  alone  is  significant 
enough  to  have  a  major  impact  on  the  demand  for  ISDN. 


The  Future 

Narrowband-ISDN  (N-ISDN)  vs.  Broadband-ISDN  (B-ISDN) 

One  possible  scenario  for  the  future  of  ISDN  is  the  deployment  of  B- 
ISDN  in  the  United  States  rather  than  N-ISDN.  With  N-ISDN,  the 
general  user  will  not  be  able  to  any  services  that  he  cannot  already 
obtain  today  at  lower  cost;  not  much  of  a  marketing  position  to  be  in  to 
pay  for  the  deployment  of  a  new  technology.  On  the  other  hand,  B- 
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ISDN  to  the  home  will  greatly  increase  the  service  and  application 
options  to  include  new  services  such  as  video  on  demand,  and  there  is 
no  question  that  a  major  factor  in  the  acceptance  of  a  new  technology 
that  carries  new  costs  is  its  entertainment  value. 

ISDN  Will  Occur 

As  one  speaker  remarked  at  the  closing  session  of  the  1987 
conference  on  Evolving  to  the  ISDN  in  North  America,  The  telephone 
companies  are  going  to  go  to  ISDN  since  it  will  save  them  money,  the 
real  question  is  whether  or  not  the  users  will  receive  any  real  benefits 
from  this."  Even  though  what  he  was  referring  to  is  more  properly 
identified  as  the  IDN,  the  "Integrated  Digital  Network,"  he  did  make 
an  accurate  statement  of  direction  for  the  public  networks  and  raise 
an  important  question  which  is  still  unanswered. 
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ISDN  Terminology  and  Concepts 

Definition  of  ISDN 

An  ISDN  is  a  network,  in  general  evolving  from  a  telephone  IDN  (Integrated 
Digital  Network),  that  provides  end-to-end  digital  connectivity  to  support  a  wide 
range  of  services,  including  voice  and  non-voice  services  to  which  users  have 
access  by  a  limited  set  of  standard,  multipurpose  user-network  interfaces. 

Basic  Concepts  of  ISDN 
Access 

•  Integrated  digital  access  to  all  telecom  services 

•  Present  situation  (Figure  A) 

••  Multiple  access  lines 
••  Some  digital,  some  analog 


Figure  A 

Present  Service  Access 


Subscriber 


•  ISDN  access  situation  (Figure  B) 
••  Single  access  line 
••  All  digital 
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Figure  B 

ISDN  Service  Access 


Models  of  the  ISDN  Interface 

Interface  Procedural  Model 

•  Figure  C 

•  Identifies  the  layers  (OSI)  involved  in  the  interaction  on  each  channel. 

••  B-channel 

•••  Information  path  only 

•••  TE1,  NT2,  and  NT1  perform  signal  conversion  only 
•••  Signalling  all  done  on  D-channel 
••  D*channel 

•••  Same  path  used  for  both  signalling  (level  3)  and  information 
transfer 

Interface  Reference  Model 

•  Figure  D 

•  Identifies  equipment  boxes  and  interfaces  between  them. 
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Figure  C 

Models  of  the  ISDN  User  Interface 


Reference 

Model 


r 


Procedural 

Model 

D-CHANNEL 


B-CHANNEL 
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ISDN  Interface  Reference  Points 


Figure  D  ISDN  Reference  Model  Interfaces 


User  Owned  - ►  ?  « - Telco  Owned 

S  T  U  V 


The  ISDN  Interfaces 
Service  Interfaces 

Basic  Rate  Interface 

•  The  Basic  Rate  Interface,  commonly  referred  to  as  the  BRI,  consists  of 
two  B  channels  (64  kbps)  and  one  D  channel  (16  kbs)  or  2B+D  for  a  total 
of  1 44  kbs  directly  usable  by  the  subscriber.  (Figure  E) 

Primary  Rate  Interface 

The  Primary  Rate  Interface  or  PRI  consists  of  23  B  channels  and  one  64  kbs  D 
channel  for  23B+D.  It  operates  at  1 .544  Mbs  in  the  US  and  2.048  Mbs  in 
Europe.  For  both  BRI  and  PRI,  the  B  channel  carries  the  user's  voice,  data  or 
image  information.  The  D  channel  carries  signaling  or  packet  data  for  the  BRI 
interface  and  only  signaling  for  PRI.  (Figure  F) 

Primary  Rate  Interface 

The  Primary  Rate  Interface  or  PRI  consists  of  23  B  channels  and  one  64  kbs  D 
channel  for  23B+D.  It  operates  at  1.544  Mbs  in  the  US  and  2.048  Mbs  in 
Europe.  For  both  BRI  and  PRI,  the  B  channel  carries  the  user's  voice,  data  or 
image  information.  The  D  channel  carries  signaling  or  packet  data  for  the  BRI 
interface  and  only  signaling  for  PRI. 


Page  Appendix  A-6 


Technical  Issues  in  Evolving  to  ISDN 


Final  Report  -  Appendix  A 


Figure  E 


The  ISDN  Subscriber  Interfaces  — 

The  Basic  User  interface 


Physical 


0 


0 


One  Pair,  144  Kbps,  FDX(using  echo  cancelling) 


Logical 


Multiple  Service  and  Control  Channels 
obtained  using  TDM  (fixed)  on  the 
single  physical  circuit 


Physical  Interface  Points 

Jhe._R  Interface 

•  An  existing  defined  non-ISDN  interface. 

The  S  interface 

•  A  standard  defined  ISDN  interface. 

•  The  S  interface  is  the  interface  between  customer’s  receiving  terminal 
and  terminal  equipment  at  customer  premise. 

The  T  Interface 

•  A  standard  defined  ISDN  interface. 

The  U  Interface 

•  NOT  defined  by  CCITT  -  ("CONTROVERSIAL"  in  the  USA). 

•  The  U  interface  is  the  connection  between  a  switch  and  customer  which 
allows  for  full-duplexed  144  kbs. 
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Figure  F 


The  ISDN  Subscriber  Interfaces  — 

The  Primary  User  Interface 


Physical 


Two  Pairs,  each  SX,  1.544  Mbps 


Loaical 


•  Telco  equipment  interface  -  being  defined. 

Basic  Rate  Interface  —  "T"  and  "U"  Bit  Rates 

•  The  bit  rate  commc-'ly  given  for  the  Basic  Rate  Interface  (BRI)  is  144 
Kbps. 

••  This  is  the  combined  bit  rate  of  the  user  channels  — 

2B+D,  (2x64)  +  16  =  144  Kbps 

••  In  addition,  there  are  framing,  control,  and  electrical  balancing  bits 
associated  with  each  bit  stream.  (Figure  G) 


At  the  S  and  T  reference  points 
••  S/T  basic  channels 

2B  channels  @ 
1 D  channel  @ 


8  bits  each 

2MtS 
1 8  bits 


••  S/T  Frame 


2  sets  of  the  2B  channels 
2  sets  of  the  D  channei 


32  bits 
4  biis 


framing,  control,  electrical  balance  1 2  bits 
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Frame  size 
S/T  line  speed 
•••  4000  frames  per  second 

48  x  4000  =  192,000  bps 
•••  Line  encoding 

••••  Pseudo  ternary  —  1  bit  per  baud 
••••  Line  operates  at  1 92,000  baud 
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48  bits 


At  the  U  reference  point 
••  U  basic  channels 

2B  channels 
ID  channel 

••  U  frame 


@ 


8  bits  each 
2  bits 
18  bits 


12  sets  of  the  2B  channels 
12  sets  of  the  D  channel 
framing,  control,  electrical  balance 
Frame  size 
U  line  speeds 

666.67  Frames  per  second 

240  x666.67  =  160,000  bps 
•••  Line  encoding 

••••  2B1Q  (2  binary,  1  Quaternary) 

2  bits  per  baud 

••••  Line  operates  at  80,000  baud 


192  bits 
24  bits 
24  bits 
240  bits 


ISDN  Equipment 

NT  -  Network  Termination 

•  NT1  -  Network  Termination  1 

••  Broadly  defined  as  functions  belonging  to  layer  1  of  the  OSI 
model.  Converts  the  characteristics  of  the  subscriber  loop  to  a 
standard  ISDN  interface.  (Primarily  a  signal  converter  and  line 
controller.) 

••  Includes  functions  broadly  equivalent  to  Layer  1  (Physical)  of  the 
OSI  Reference  Model. 

••  These  functions  are  associated  with  the  proper  physical  and 
electromagnetic  termination  of  the  network. 

••  NT1  functions  are 

•••  Line  Transmission  Termination 
•••  Layer  1  Line  Maintenance  Functions  and  Performance 
Monitoring 
•••  Timing 
•••  Power  Transfer 
•••  Layer  1  Multiplexing 

•••  Interface  Termination,  including  Multidrop  Termination 
employing  Layer  1  Contention  Resolution 
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es 


At  the  S  and  T  reference  points 
S/T  basic  channels 
2B  channels  @  8  bits  each 
1 D  channel  @  2  bits 
16  bits 

S/T  frame 

2  sets  of  the  2B  channels  32  bits 
2  sets  of  the  D  channel  4  bits 

framing,  control,  electrical 
balance  12  bits 

Frame  size  48  bits 

S/T  line  speed 
4000  frames  per  second 
48  X  4000  =  192,000  bps 
Line  encoding 

Pseudo  ternary  —  1  bit  per  baud 
Line  operates  at  192,000  baud 


U  basic  channels 

2B  channels  @  8  bits  each 
ID  channel  @  2  bits 
TTEIts 

U  frame 

12  sets  of  the  2B  channels  192  bits 
12  sets  of  the  D  channel  24  bits 

framing,  control,  electrical 
balance  24  bits 

Frame  size  240  bits 

U  line  speed 
666.67  frames  per  second 
240  x  666.67  =  160  bps 
Line  encoding 

2B1Q  (2  binary,  1  Quaternary) 

Line  operates  at  80,000  baud 


•  NT2  -  Network  Termination  2 

••  Combines  the  output  of  several  ISDN  interfaces  (terminals)  for 
presentation  over  a  single  ISDN  interface  (e.g.  PABX,  key  set, 
LAN  controller). 

••  Includes  functions  broadly  equivalent  to  Layer  1  and  higher  layers 
of  CCITT  Recommendation  X.200,  the  OSI  Reference  Model. 

••  PABXs,  Local  Area  Networks,  and  Terminal  Controllers  are 

examples  of  equipment  or  combinations  of  equipment  that  provide 
NT2  functions. 

••  NT2  functions  include 

—  Layers  2  and  3  Protocol  Handling 
•••  Layers  2  and  3  Multiplexing 
•••  Switching 
•••  Concentration 
•••  Maintenance  Functions 

•••  Interface  Termination  and  other  Layer  1  Functions 


•  NT  Examples 

••  A  PABX  can  provide  NT2  functions  at  1 , 2  and  3. 
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••  Simple  terminal  controllers  can  provide  NT2  functions  at  only 
Layers  2  and  2. 

••  In  a  specific  access  arrangement,  the  NT2  functional  group  may 
consist  of  only  physical  connections. 

TE  -  ISDN  Terminal  Equipment 

•  Includes  functions  broadly  belonging  to  Layer  1  and  higher  layers  of  the 
X.200  OSI  Reference  Model. 

••  Digital  telephones,  data  terminal  equipment,  and  integrated 
workstations  are  examples  of  equipment  or  combinations  of 
equipment  that  provide  the  functions. 

••  The  TE  functions  are 
•••  Protocol  handling 
Maintenance  functions 
•••  Interface  functions 

•••  Connection  functions  to  other  equipment 

•  TE1  -  Terminal  Equipment  Type  1 

••  Figure  H 

••  Conforms  to  an  ISDN  standard  interface. 

••  Includes  functions  belonging  to  the  Functional  Group  TE,  and  with 
an  Interface  that  complies  with  the  ISDN  User-Network  Interface 
Recommendations. 

•*  Multiple  TEIs  on  a  single  S-Bus  (Figure  I) 

•  TE2  -  Terminal  Equipment  Type  2 

••  Interface  conforms  to  a  standard  other  than  ISDN. 

••  Includes  functions  belonging  to  the  Functional  Group  TE  but  with 
an  Interface  that  complies  with  Interface  Recommendations  other 
than  the  ISDN  Interface  Recommendation  (e.g.,  the  X-Series 
Interface  Recommendations)  or  interfaces  not  included  in  CCITT 
Recommendations. 

TA  —  ISDN  Terminal  Adapter 

•  Allows  existing  equipment  to  conform  to  a  standard 

•  Includes  functions  broadly  belonging  to  Layer  1  and  higher  layers  of  the 
OSI  Reference  Model  that  allow  a  TE2  Terminal  to  be  served  by  an 
ISDN  user-network  interface. 

•  Adaptors  between  physical  interfaces  at  reference 

points  R  and  S  or  R  and  T  are  examples  of  equipment  or 
combinations  of  equipment  that  provide  TA  Functions. 

LT —  Line  Termination 

•  Provides  the  termination  of  the  subscriber  loop  at  the  central  office  end. 
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ET  —  Exchange  Terminations 

•  Provides  the  functions  required  for  interfacing  the  subscriber  line  to  the 
exchange. 


ISDN  Services 
ISDN  Channel  Types 

Narrowband  ISDN  Channels 
B-Channel 

•  The  basic  ISDN  Digital  Information  Channel 

•  Capacity 

«  64  KBit/s 

•  Signal  Types 

••  PCM  Voice 

••  Wide  Band  Speech  (7  KHZ) 

••  Image  (single  frames) 

••  Digital  Data  (to  64  KBit/s) 

••  Subrate  Digital  Data  (less  than  64  Kbps) 
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•  Information  Transfer  Mode 
••  Circuit  Switched 
••  Packet  Switched 

••  Private  Line  (i.e.,  dedicated,  not  switched) 


•  Signalling 

••  Out-of-Band,  carried  separately  on  Associated  D  Channel 


D-Channel 

•  Used  for 

••  Signalling 

*•  Switched,  Packet  Data  Network  access 

•  Capacity 

••  16  Kbps  -  for  basic  access,  with  2  or  fewer  B  Channels 

••  64  Kbps  -  for  primary  rate  access,  with  more  than  2  B  Channels 

•  Signal  Types 

••  Signalling  for  B  or  Wideband  Channels 
••  Packet  Type  Data 
••  Telemetry,  etc. 

•  Information  Transfer  Mode 

••  Packet  Switched 
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••  In-band,  within  the  D  Channel  protocol 


HO-Channel 

•  A  Broadband  Digital  Channel 

•  Capacities 

••  HO  -  384  KBit/s 

•  Signal  Types 

••  HO 

•••  High  quality  audio 

Other  high  speed  digital  information 

•  Information  Transfer  Mode 

••  Initially  private  line  only 
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HI -Channel 

•  Broadband  Digital  Channels 

•  Capacities 

••  H1 1  -  1 536  KBit/s  (4HO  channels) 
••  HI 2  -  1920  KBit/s  (5HO  channels) 

•  Signal  Types 

••  H1 1,  H12 

•••  Video  for  teleconferencing 
•••  High  speed  digital  information 

•  Information  Transfer  Mode 

••  Initially  private  line  only 


Establishment  of  Standards 

Currently,  the  CCITT  and  their  ISDN  study  groups  are  responsible  for  the 
development  of  recommendations  for  international  ISDN  standards.  The  CCITT 
is  a  branch  of  an  arm  of  the  United  Nations,  the  International 
Telecommunications  Union  (ITU).  Most  European  countries  are  represented  in 
the  CCITT  by  their  PTTs  (Postal  Telegraph  and  Telecommunications).  The  U.S. 
representative  to  the  CCITT  is  the  American  National  Standards  Institute  (ANSI) 
T1  Standards  Committee,  an  organization  sponsored  by  the  Exchange  Carriers 
Standards  Association  (ECSA).  The  T1  subcommittee  focusing  on  ISDN  is 
called  T1D1.  The  T1D1  subcommittee  participates  in  CCITTs  international  body 
related  to  ISDN  standards  and  also  proposed  ISDN  standards  unique  to  U.S. 
networks  pending  approval  by  ANSI.  In  addition  to  ECSA,  the  Open  System 
Interconnection  (OSI)  technical  subcommittee  is  responsible  for  ISDN 
standards  for  the  seven-layer  OSI  model. 

North  America  vs.  The  World 

U.S.  standards  organizations  involved  with  ISDN  standards  include:  the 
National  Institute  for  Standards  and  Technology  which,  in  the  past  year,  formed 


Page  Appendix  A-14 


Technical  Issues  in  Evolving  to  ISDN  Final  Repon  -  Appendix  A 

the  North  American  ISDN  Users  Forum;  Bell  Communication  Research 
(Bellcore);  the  Corporation  for  Open  Systems  (COS);  the  Electronics  Industries 
Association  (EIA);  the  Institute  for  Computer  Sciences  and  Technology  (ICST); 
the  Institute  of  Electrical  and  Electronic  Engineerings  (IEEE);  and  the 
International  Electrotechnical  committee  (IEC). 

ISDN  standards  relate  closely  to  the  ISO  seven-layer  reference  model  for  Open 
System  Interconnection  (OSI).  ISDN  and  OSI  standards  are  independent  of 
each  other,  but  the  ISDN  protocols  were  developed  with  the  OSI  framework  in 
mind.  ISDN  occupies  the  lowest  three  layers  of  the  OSI  model:  Physical  Layer 
1 ;  Data  Link  Layer  2;  and  the  Network  Layer  3.  OSI  and  ISDN  are 
complimentary  standards  that,  in  the  future,  will  allow  different  networks  to 
interoperate. 

The  current  standards  for  ISDN  are  the  1-Series  Recommendations  which  are 
summarized  in  this  section.  The  1.100  Series  is  a  comprehensive  introduction  to 
ISDN,  describing  fundamental  ISDN  principles,  terminology,  characterization 
and  methods.  The  1.200  Series  describes  ISDN  services  including  bearer 
services  and  teleservices.  The  1.300  Series  describes  network  aspects  of  ISDN. 
These  include  network  functional  principles;  an  ISDN  reference  model; 
numbering;  addressing,  and  routing  principles;  connection  types;  and 
performance  objectives,.  The  1.400  Series  includes  different  versions  of  the 
interface  between  users  and  the  network.  This  includes  specifications  for  BRI 
and  PRI.  Layers  1,  2,  and  3  specifications  for  the  S  and  T  reference  points 
are  also  provided  along  with  the  procedures  for  adapting  non-ISDN  terminals  to 
an  ISDN  network. 

ISDN  standards  have  moved  rapidly  in  the  past  two  years  and  are  virtually 
completed  with  two  notable  exceptions:  Q.931  signaling  at  Layer  3  and  Q.932 
special  services.  Most  of  the  standards  activity  with  regard  to  Q.931  is  expected 
to  be  resolved  by  the  third  quarter  of  1990.  A  recent  development  is  the 
standardization  of  the  2B1Q  line  code  which  is  specified  for  North  America 
(other  countries  have  adopted  different  coding  techniques).  A  line  code  is  the 
electrical  representation  of  the  digital  signals,  the  actual  "Is"  and  "0s" 
transmitted.  To  this  pattern  of  pulses,  2B1Q  adds  adaptive  digital  signal 
processing  (which  smooths  out  interference  on  a  line)  to  create  the  capability  of 
using  ordinary  telephone  twisted  pair  wiring  for  distances  up  to  18,000  feet. 

The  "U"  Interface 

Public  Network  Numbering  Plans 

•  The  CCITT  has  developed  several  numbering  plans  for  public  networks 
••  E.1 64  —  "Numbering  Pan  for  the  ISDN  ERA" 

•••  An  international  numbering  plan  for  the  worldwide  networking 
of  voice  and  data 

•••  Specifies  an  international  address  less  than  or  equal  to  15 
decimal  digits 

Until  31  December,  1996,  the  maximum  length  of  an 
ISDN  address  is  limited  to  12  digits.  This  restriction  was 
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added  to  make  the  transition  from  the  PSTN  numbering 
plan  easier  (see  below) 

The  ISDN  number  consists  of  a  country  code  of  up  to  3 
digits  and  a  "nationally  defined  national  significance 
number  (NSN)" 

••  E.163  —  "Numbering  Plan  for  the  International  Telephone 
Service" 

••  X.121  —  "International  Numbering  Plan  for  Public  Data  Networks" 
•••  Applicable  to  all  public  data  networks  (PDNs),  both  packet- 
switched  and  circuit-switched 
•••  An  international  address  of  14  digits  or  less 
••••  Format  1 

♦••••  Data  Country  Code  (DCC)  -  3  digits,  "ZXX"  where 
Z  =  2-7  and  X  =  0-9 

.....  National  Terminal  Number  (NTN)  -  up  to  1 1  digits, 
"XXXXXXXXXXX" 

••••  Format  Z 

.....  Data  Network  Identification  Code  (DNLC)  -  4 
digits,  "DCC+X" 

.....  National  Terminal  Number  (NTN)  -  up  to  10  digits, 
"XXXXXXXXXX" 

•••  Also  specifies  an  international  prefix  digit  that  can  be  defined 
and  used  by  the  national  authorities 
•••  BellCore  has  defined  a  pseudo  DNIC  code  of  9001  to  be  used 
for  the  North  American  ISDN  field  trials 
••  F.69  —  "Plan  for  TELEX  Destination  Codes " 

•••  Specifies  2  or  3-digit  country/region  codes 

•  Problems  —  current  and  future 

••  As  ISDN  evolves,  the  operation  of  these  various  numbering  plans 
must  be  coordinated 

"E.163  Systems"  (PSTNs)  must  become  integrated  into  the 
ISDN  and  adopt  the  E.164  numbering  system 
•••  "X.121  Systems"  (PDNs  both  packet  switched  and  circuit- 
switched)  must  immediately  internetwork  with  the  ISDN  and 
its  numbering  plan  and  must  eventually  be  fully  integrated  into 
the  E.164  plan. 

••  A  recent  meeting  of  the  CCITT  special  group  on  addressing 
identified  over  50  different  scenarios  describing  various 
internetworking  and  evolution  situations. 
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Background 

The  doctoral  research  of  Koo-Don  Chung  was  originally  motivated  by  this 
project  and  the  interest  in  studying  the  access  protocol  for  the  D-Channel  of  the 
Basic  Rate  Interface.  All  of  the  characteristics  of  this  protocol  are  of  interest; 
however,  Chung’s  detailed  research  focused  on  the  issues  of  fairness  and 
efficiency.  Other  characteristics  such  as  robustness  and  measured 
performance  required  instrumentation  capabilities  in  the  experimental  facility 
that  were  not  available  in  time  for  Chung's  work. 


Characterizing  the  D-Channel  and  Outline  of  Work 

Chung  considered  the  D-Channel  protocol  to  utilize  one  form  of  "cyclic 
transmission  control.”  Quoting  from  his  thesis,  "Data  Transfer  over  Multiplexed 
Logical  Data  Links  Sharing  a  Single  Physical  Circuit,"  Georgia  Institute  of 
Technology,  Atlanta,  Georgia,  1990. 

"This  thesis  examines  the  performance  and  the  characteristics  of  the  data 
transfer  over  a  single  physical  circuit  which  is  shared  by  multiple,  logical  data 
links.  In  the  sharing  of  the  communication  medium,  a  proper  transmission 
control  (or  multiplexing)  scheme  must  be  utilized.  In  particular, . . .  cyclic 
transmission  control  schemes  [are  considered]  in  which,  at  most  one  data  unit 
(or  frame)  for  each  logical  data  link  user  can  be  transmitted  in  each 
transmission  cycle.  This  type  of  transmission  control  has  been  extensively 
studied  during  the  last  two  decades.  However,  an  exact  analysis  has  not  been 
derived  except  for  some  special  cases. 

"First, ...  an  approximate  analysis  [is  presented]  for  the  cyclic 
transmission  control  scheme  which  is  modeled  by  a  number  of  M/GA  queues 
served  by  a  single  server  in  a  cyclic  manner.  Then,  the  analysis  is  extended  for 
systems  with  /WM/G/1  queues.  Extensive  computer  simulation  results  verify  that 
the  analysis  yields  accurate  estimates  of  the  mean  waiting  time  and  the  cycle 
time  variances  for  a  wide  range  of  parameters  values.  Comparisons  with 
several  well-known  approximations  are  also  presented. 

"Next, . . .  systems  with  multiple-priority  queues  [are  considered].  The 
stability  conditions  for  individual  queues  and  the  conversation  law  for  each 
priority  class  are  derived.  An  approximation  formula  for  the  mean  waiting  time 
of  individual  queues  [is]  also  presented.  Simulation  results  show  that  the 
formula  yields  accurate  estimates  of  the  mean  waiting  times  when  the  traffic  for 
the  queues  within  each  priority  class  is  not  very  heavy  and  not  highly 
asymmetric. 

"Finally,  ...  the  effect  of  cyclic  transmission  control  on  window  flow- 
control  mechanism  [is  examined].  The  properties  and  the  performance  of 
several  alternative  acknowledgement  strategies  are  compared  by  means  of 
computer  simulations  and  worst  case  analyses." 
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Contention  on  the  ISDN  D-Channel 

"[Contention]  access  control  is  implemented  on  the  D-channel  at  the 
ISDN  basic  rate  user  interface.  In  this  protocol,  all  the  transmissions  by  the 
users,  Terminal  Equipment  (TEs)  in  ISDN  terminology,  are  synchronized.  Each 
TE  can  read  each  'bit'  (0  or  1 )  transmitted  on  the  channel  which  is  echoed  by 
the  terminal  controller,  Network  Termination  (NT)  in  ISDN  terminology,  on  a 
separate  channel  called  the  D-Echo  channel.  A  TE  is  allowed  to  send  data  if  it 
detects  an  idle  channel,  which  is  identified  by  counting  a  number  of  consecutive 
I's  on  the  D-Echo  channel.  Therefore,  all  the  frames  must  be  protected  from  the 
false  indication  of  an  idle  channel  which  is  achieved  by  the  technique  known  as 
bit  stuffing.  Channel  access  priorities  are  defined  by  using  different  definitions 
of  idle  channel,  i.e.,  a  TE  which  wants  to  send  a  frame  with  higher  priority  counts 
a  smaller  number  of  Vs  than  all  the  TEs  which  have  frames  with  lower  priority. 
Within  each  priority  class,  round-robin  priority  rule  is  enforced  as  follows.  If  a  TE 
successfully  transmits  a  frame,  it  temporarily  lowers  its  own  priority  level  until 
the  current  cycle  completes  which  is  recognized  by  detecting  an  idle  channel 
with  its  temporary  priority.  It  returns  to  its  original  priority  upon  detection  of  the 
end  of  the  current  cycle. 

"If  more  than  one  TE  transmits  at  the  same  time,  this  situation  usually 
occurs  at  the  end  of  a  frame  transmission  if  there  is  more  than  one  TE  waiting 
for  the  channel  to  become  idle,  then  the  data  transmitted  on  the  output  channel 
is  defined  as  the  result  of  a  logical  '01^  operation  on  all  the  bits  transmitted  at 
that  time.  The  conflicts  for  channel  access  (or  collisions)  are  detected  at  each 
transmitting  TE  by  comparing  each  bit  in  the  [address  it  transmits  with  the 
address  bits  echoed  on  the  D-Channel]. 

"The  D-channel  access  control  protocol  can  now  be  summarized  as 
follows  (see  CCITT  1.430]  for  a  complete  description  of  the  protocol).  If  a  TE  has 
data  to  send,  it  first  determines  whether  or  not  the  output  channel  is  idle 
according  to  the  history  of  the  bits  transmitted  on  the  channel.  If  the  channel  is 
busy,  the  TE  must  wait  until  the  channel  becomes  idle.  If  the  channel  is  idle,  it 
transmits  the  data  according  to  the  following  procedure. 

1 .  Let  /  =  1 . 

2.  Transmit  the  bit  in  the  data. 

3.  Read  the  bit  transmitted  on  the  D-echo  channel. 

4.  If  a  collision  is  detected,  then  wait  until  the  channel  becomes  idle  and 
restart  the  transmission  from  the  beginning. 

5.  If  all  the  bits  in  the  data  are  transmitted,  then  STOP.  Otherwise,  set 
/  =  /  +  1  and  then  GOTO  step  2. 
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"Figure  2.2  illustrates  an  example  of  collision  resolutions  within  the  D- 
channel  access  protocol.  This  protocol  is  collision  free  in  a  sense  that  there  is 
always  one  TE  which  completes  its  transmission  even  if  more  than  one  TE  starts 
to  transmit  at  the  same  time.  The  transmission  cycle  time  can  now  be 
expressed  as 


Tc  =  £(T<  +  T«j)  (2.4) 

ieSU 

Where  T1  denote  the  time  required  by  each  TE  to  detect  an  idle  channel. 

"Note  that  the  transmission  cycle  times  in  (2.3)  and  (2.4)  may  be 
considered  as  polling  cycle  times  without  switchover  times  by  including  the 
scheduling  overheads,  T°j  or  T1,  into  the  data  transmission  times  T  T°j  or  all  i.  For 
this  reason,  we  will  refer  to  the  transmission  schemes  in  which  the  transmission 
cycle  times  can  be  expressed  in  the  form  of  (2.4),  i.e.,  Tc  is  not  affected  by  the 
users  not  sending  data  in  that  cycle,  as  cyclic  transmission  control  schemes 
without  or  zero  switchover  times.  Figure  2.3  shows  the  differences  in  the  cyclic 
transmission  control  schemes  presented  above. 


Motivation  for  Analytic  Approach  Taken  in  this  Research 

"The  basic  underlying  motivation  for  the  approach  taken  here  is  a  goal  to 
develop  an  analytical  model  suitable  for  analyzing  the  performance  of  the  ISDN 
D-channel.  When  the  operation  of  the  D-channel  access  protocol  is  analyzed,  it 
is  seen  that  the  D-channel  operation  can  be  modeled  as  a  cyclic  service  system 
with  zero  switchover  times." 


Some  of  Chung's  findings  were: 

"The  multiplexing  effect  in  multiplexed  logical  data  links  was  examined.  It 
was  observed  that  the  acknowledgement  delay  in  LAPD  protocol  increases  as 
the  number  of  logical  data  links  increases.  This  makes  it  difficult  to  determine 
link  parameter  values,  window  size,  and  timeout  intervals,  especially  when  the 
number  of  active  logical  data  link  is  large  or  changing  dynamically  over  time. 

"[S]ome  alternative  approaches  [are  presented]  as  remedies  to  the 
multiplexing  effect.  NOPIG  [no  piggyback  acknowledgements]  shows  better 
performance  than  . . .  LAPD  in  the  average;  however,  [it]  may  not  be  acceptable 
in  some  applications  because  of  the  starvation  problem.  The  stand-alone 
acknowledgement  strategy  with  priority  [Rei79]  works  the  same  as  NOPIG  at  the 
user-network  interface. 

"With  PRACK  [priority  acknowledgements]  and/or  SEPEF  [separation  of 
error  control  and  flow  control],  the  average  performance  can  be  improved 
significantly  over  the  LAPD  protocol.  The  multiplexing  effect  on 
acknowledgement  delay  in  both  PRACK  and  SEPEF  is  shown  to  be  bounded 
by  a  constant  time.  This  property  is  very  important  because  the  parameter 
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values  can  be  determined  without  the  need  to  consider  the  number  of  active 
links.  Tho  concept  used  in  PRACK  and  SEPEF  can  be  integrated  into  a  single 
system  such  as  the  basic  rate  user  interface  of  ISDN. 

"With  PRACK,  substantial  portions  of  channel  bandwidth  may  not  be 
utilized  for  the  user  data  transmission  because  of  the  need  to  transmit  additional 
S-frames.  It  is  demonstrated  that  the  number  of  additional  S-frame 
transmissions  can  be  reduce  significantly  by  proper  selection  of  the  frame 
lengths  and/or  the  timing  of  acknowledgements  (deferred  acknowledgement). 
Determining  the  optimum  value  of  the  frame  lengths  and  optimum  timing  of 
acknowledgement  requires  further  study. 

"It  may  be  not  be  easy  to  implement  SEPEF  on  the  multiple  physical 
terminal  configurations,  e.g.  basic  rate  user  interface  in  ISDN,  without  having 
extra  communication  mechanisms  among  MUXPs  at  different  physical 
terminals.  In  the  ISDN  basic  rate  user  interface,  due  to  the  D-echo  channel 
[1.430],  a  MUXP  can  receive  all  the  frames  transmitted  by  any  local  DLP  even  if 
the  DLP  is  located  in  different  physical  terminal.  One  possible  approach  is  to 
make  use  of  the  D-echo  channel  for  coordination  among  the  MUXPs  at  different 
physical  terminals.  It  is  also  possible  to  apply  SEPEF  in  each  physical  terminal 
but  use  PRACK  and  among  the  MUXPs  in  different  physical  terminals.  The 
solution  to  this  problem  is  beyond  the  scope  of  this  study." 
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Figure  2.2 

Collision  Resolution  in  D-Channel 
Access  Control  Protocol 
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ISDN  and  SS7 


ICS  8501  :  SPECIAL  PROBLEMS 


Part  1  :  LAPB/LAPD 


Special  Problems 


I-  Introduction. 

In  the  packet  mode  services  of  ISDN,  one  could  use  X25-LAPB  or 
X25-LAPD  on  the  B  channel.  The  choice  is  not  obvious  between  the 
former  and  the  latter  :  some  requirements  ask  for  LAPB,  others  for 
LAPD.  Looking  at  both  the  user  and  the  system  point  of  view,  what 
are  the  points  behind  using  each  of  them  over  the  B  channel  ?.  What 
are  the  technical  solutions  for  solving  the  problem  ?  What  is  a  new 
model  for  ISDN  in  packet  services  ?. 

There  is  an  arising  question  concerning  the  protocol  architecture  to 
be  used  when  accessing  the  ISDN  packet  mode  services.  It  is  whether 
we  should  use  X25-LAPB  or  X25-LAPD  in  the  place  of  LAPX  in  Figure 
1,  over  the  line  between  the  user  (  TA  or  TE1  )  and  the  Local 
Exchange  (  LE  ). 

Our  goal  in  this  paper  is  to  look  closer  at  the  points  for  each  of  them 
and  try  to  constructively  criticize  the  arguments  that  are  discussed  in 
the  literature.  We  will  first  consider  the  environment  of  the  problem, 
and  the  typical  uses  that  are  made  of  ISDN,  and  then  examine  the 
reasons  why  LAPD  has  been  recommended. 

We  will  consider  the  two  possible  types  of  terminals  that  access  the 
network  :  TE1  is  the  ISDN  terminal,  not  yet  available,  that  connects 
directly  to  the  Network  Termination  point  (  NT  )  ;  TE2  is  the  actual 
X25  terminal,  that  needs  an  adaptor  to  connect  to  the  NT  point.  These 
two  do  use  different  access  techniques  :  where  TE1  uses  LAPD.  TE2 
uses  LAPB  to  the  TA,  that  itself  uses  LAPD. 


Figure  1  :  general  ISDN  packet 

TA=Terminal  Adapter 
TEl=Terminal  Equipment  Typel 
TE2  =  Terminal  Equipment  Type2 


mode  access 
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The  use  of  LAPD  over  the  D-channel  is  of  no  discussion.  It  is  now 
established  that  LAPD  is  used  over  the  D-channel  for  uniformly 
accessing  any  ISDN  service. 

The  point  here  is  to  whethci  the  user  should  implement  LAPS  or 
LAPD  over  the  B-channel  when  accessing  the  packet  services  of  ISDN. 
We  assume  thus  that  a  connection  has  been  set  up  between  the 
terminal  and  the  local  exchange.  The  choice  will  be  made  under  two 
criteria  :  the  user  access  has  to  follow  the  principles  defined  under 
ISDN  (access  simplicity,  uniformity,  ...),  and  the  network  must  the 
same  services  with  the  same  quality  as  those  foreseen  in  the  future 
ISDN. 

There  are  two  possible  configurations  of  ISDN-user  access  to  packet 
services,  called  the  minimum  integration  and  the  maximum 
integration.  These  two  scenarios  will  actually  be  consecutively 
implemented  in  the  network,  and  correspond  to  two  phases  in  the 
development  of  ISDN. 

II-  Iayq _ Scenarios  _ Mlnimuirr  _ Maximum  Integration. 

In  the  development  of  ISDN,  one  gene. ally  identifies  two  phases. 

The  first  one  is  called  the  minimum  integration  scenario,  and  refers 
to  the  case  where  the  user  accesses  packet  services  only  the  B 
channel.  Actually,  a  pipe  is  set  to  a  PSPDN  node  that  performs  the 
interworking  function  with  ISDN,  and  serves  the  user. 

The  second  is  called  the  maximum  integration  scenario,  and  allows 
the  user  to  access  packet  services  through  both  D  and  B  channels.  The 
former  is  used  for  fast  packet  switching,  and  the  latter  for  normal 
packet  switching,  with  a  circuit  set  up  between  the  terminal  and  a 
unit  in  the  network,  the  packet  handler,  responsible  for  servicing  the 
packets. 

Before  looking  at  what  this  means  for  the  access  protocols,  let  us 
explain  what  Frame  Relaying  is,  and  how  it  works. 

II. 1  Frame  Relaving  :  the  Backbone  of  the  Reliable  Network.! 4  1 

When  establishing  a  virtual  circuit  between  two  points,  one  does  not 
see  the  extreme  overhead  implied  by  the  operation  of  the  protocols 
layer  2  and  layer  4  error  control  and  flow  control,  .... 

In  fact,  these  functions  are  necessary  in  a  pure  sense.  They  were 
defined  at  times  where  the  lines  and  the  equipments  were  not  as 
reliable  as  they  are  nowadays  A  lot  of  error  checking  had  to  be 
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performed,  in  order  to  be  sure  to  overcome  the  possible  errors 
occuring  in  the  equipments. 

Now,  very  low  error  rates  are  achieved  over  physical  lines,  between 
equipments  that  are  faster  and  more  reliable.  This  tendency  lead  to 
the  definition  of  a  more  appropriate  mode  of  transmission  :  frame 
relay,  to  be  used  in  the  future  ISDN. 

Frame  Relay  is  a  packet  switching  technique  and  is  used  for  packet 
mode  bearer  services.  It  takes  the  most  out  of  the  Data  Link  layer 
multiplexing  defined  in  LAPD.  In  frame  relaying,  the  network 
functions  for  data  transfer  are  reduced  to  a  core,  that  allows  for 
minimal  network  overhead  :  frame  delimiting,  alignment, 
transparency,  frame  multiplexing,  demultiplexing,  frame  length 
checking,  and  detection  of  transmission  errors. 


User  Network  User 


Flow  control  functions  and  error  control  functions  are  not  offered. 
Errored  frames  are  discarded. 

The  frame  relaying  service  cannot  be  offered  to  non-ISDN  terminals, 
but  : 

-  X31,  which  defines  the  access  of  X25  terminals  to  ISDN,  just 
encapsulates  the  X25  services  in  an  ISDN  physical  layer 
envelope  [4], 

-  Out-of-band  control  is  a  basic  characteristic  of  frame  relaying. 

X25  uses  the  same  virtual  circuit  for  call  control  and  data.  They 

can  be  separated  by  providing  2  different  DLCIs,  and  thus 
LAPB  cannot  be  used. 

II. 2  The  Minimum  Integration  Scenario. 

In  this  phase,  supposedly  the  first  one,  ISDN  will  provide  packet 

services  on  the  B-cha..nel  only.  The  user  accesses  the  D-channel.  sets 

up  a  64  kb/s  circuit,  or  pipe,  on  the  B-channel  to  a  Packet  Switched 
Public  Data  Network  (  PSPDN  )  node,  responsible  for  the  interworking 
function  between  ISDN  and  the  PSPDN  it  is  attached  to  (see  Figure  2) 
This  configuration  is  interesting  for  large  rates,  since  we  want  to 
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make  the  best  use  of  the  64  kb/s.  However,  most  of  the  time,  a 
smaller  rate  will  be  used,  and  the  maximum  integration  phase  will 
provide  these  smaller  rates. 

On  a  protocol  point  of  view,  LAPD  is  used  on  the  D  channel  and  LAPB 
can  be  used  on  the  B  channel  since  the  minimum  integration  scenario 
provides  the  user  with  a  pipe  through  ISDN  to  an  interworking  node 
in  a  PSPDN.  This  node,  even  if  it  may  use  any  of  the  33  possible 
internal  protocols  in  packet  networks,  would  logically  require  LAPB 
on  the  B -channel  connection  with  the  user.  However,  since  it  is  an 
interworking  unit,  any  protocol  could  technically  be  used. 


Figure  2  :  connection  strategy  for  the 
minimum  integration  case 

Comparing  the  use  of  LAPD  or  LAPB  over  the  B  channel,  it  seems  to 
us  that  the  following  points  can  be  made  for  each  of  them  : 

-  Technically,  LAPD  or  LAPB  can  be  used.  There  is  however  a 
conversion  required  at  the  TA  and  IWF  functional  units  if  using 
LAPD  on  the  B  channel.  There  are  none  for  LAPB. 

LAPB  provides  for  a  uniform  end  to  end  communication. 

-  Using  LAPD  over  the  B  channel  would  make  the  user-network 
interface  more  uniform,  since  it  already  uses  LAPD  for  the  D 
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channel.  LAPD  provides  for  a  uniform  user  access  to  the  packet 
services. 

In  the  minimum  scenario,  we  recommend  that  the  stack  used  be  the 
one  below.  Another  practical  reason  for  not  moving  the  B  channel 
layer  2  protocol  to  LAPD  is  that  in  the  minimum  integration 
configuration,  most  of  the  users  of  packet  services  are  'old'  packet 
terminals.  These  terminals  use  X25  stacks,  and  replacing  all  of  them 
would  not  make  sense  for  the  users.  The  point  behind  the  minimum 
integration  phase  is  to  allow  previous  configurations  to  be  able  to  use 
ISDN  services,  and  users  of  'old'  packet  terminals  to  move  smoothly 
to  ISDN  terminals. 


-  sets  up  a  circuit  from 
D  channel  user  to  IWF. 

-  carries  control  information 


-  the  circuit  is  used  as  a  PVC. 
B  channel  -  proprietary  user  protocol 
carried  transparently. 


I. 

451 

I. 

441 

I. 

430 

X25 

LAPB 

RS232 


Minimum  integration  scenario 

IL3  The  Maximum  Integration  Scenario. 

This  scenario  is  the  next  stage,  after  the  minimum  integration,  in  the 
development  of  ISDN.  The  basic  difference  for  the  user  is  that  he  will 
be  able  to  access  packet  services  on  both  channel  B  and  channel  D. 

For  the  B  access,  the  principles  are  the  same  :  the  user  sets  up  a  pipe. 
But  this  time  there  is  an  entity  in  the  network  that  takes  care 
directly  of  the  packet,  instead  of  routing  it  to  a  PSPDN  'server'.  This 
entity  is  called  the  Packet  Handler  (  PH  ).  It  is  not  a  physical 
component,  like  a  computer,  but  rather  a  function  of  the  network, 
w'hich  can  be  implemented  anywhere  :  at  the  local  exchange,  at  the 
central  office,  or  in  any  centralized  unit.  The  place  w'here  it  woll  be 
implemented  will  be  function  of  the  level  of  integration  in  the 
network.  The  ideal,  of  course,  is  for  it  to  be  as  close  to  the  user 
premises  as  possible,  since  a  circuit  will  be  established  between  the 
PH  and  the  user  for  packet  transmission,  as  there  was  a  circuit 
between  the  user  and  the  IWF  in  the  previous  stage. 
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For  the  D  access,  referred  to  as  fast  packet  switching,  the  user  does 
not  have  to  set  up  a  circuit.  It  rather  uses  the  D  channel  in  a 
datagram  manner,  sending  a  packet  to  the  PH,  which  primary 
function  is  to  separate  control  information  from  user  information, 
the  C-plane  and  U-plane,  flowing  on  the  D  channel.  PH  then  re-routes 
the  packet  to  a  PSPDN,  using  the  interworking  protocol  stack  X75  or 
X75\  This  interwork  protocol  uses  LAPB  in  its  layer  2. 


B. 

D. 


Maximum  integration  scenario  :  packet  services  access 
using  the  Packet  Handler  functionality. 

The  points  for  both  protocols  in  this  configuration  are  the  following  : 

-  using  LAPB  or  LAPD  as  a  matter  of  uniformity  has  the  same 
advantages  and  drawbacks  as  in  the  minimum  integration 
scenario. 

-  There  is  an  additional  point  for  LAPD  though,  that  will  be 
better  understood  in  a  later  section.  LAPD  is  used  in  Frame 
Relay  mechanism,  instead  of  LAPB,  because  it  allows  for  layer  2 
multiplexing.  As  we  will  see  later,  this  is  a  fundamental 
characteristic  of  Frame  Relaying. 

Following  the  previous  recommendations,  the  stack  used  on  the 
channels  should  be  the  one  below. 
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D  channel 


B  channel 


-  sets  up  a  circuit  from 
user  to  1WF. 

-  carries  control  information 
and  fast  packets. 

-  the  circuit  is  used  as  a  PVC. 

-  proprietary  user  protocol 
carried  transparently. 


Maximum  integration  scenario 


11.4  Summary . 

In  using  LAPB  or  LAPD,  from  the  user  side,  there  are  equivalent 
arguments  for  both  of  them  as  a  matter  of  uniformity.  LAPB  ensures 
uniformity  along  the  data  path  to  the  packet  network,  and  probably 
to  the  other  end  of  the  communication,  since  LAPB  can  be  used 
internally  in  the  PSPDN.  LAPD  ensures  a  uniform  user  access  to  the 
network,  considering  both  the  B  and  D  accesses. 

Depending  on  the  scenario,  there  is  however  additional  points  for 
each  : 


-  in  the  minimum  case,  LAPB  is  widely  used.  It  is  hard  to  ask 
the  user  to  change  his  equipments. 

-  In  the  maximum  case,  if  frame  relay  is  used,  LAPD  is  a 
requirement  for  a  uniform  end  to  end  communication. 

Actually,  these  changes  are  not  surprising.  The  two  configurations 
defined  in  ISDN  correspond  to  two  phases,  and  two  different  sets  of 
users.  In  the  minimum  case,  we  are  trying  to  integrate  the  old  users 
to  the  network,  meaning  those  who  use  old  terminals  with  LAPB.  In 
the  maximum  case,  it  is  assumed  that  users  will  have  moved  io  ISDN 
terminals  (  the  TE1  ),  and  thus  will  have  changed  most  of  their 
equipments. 

Discussing  the  validity  of  such  changes  would  end  up  debating  on 
whether  the  users  know  where  their  interests  are.  LAPD  is  defined 
as  a  'super  LAPB’,  providing  multiplexing  and  thus  allowing  for  out- 
of-band  control  communications.  In  the  few  studies  that  have  been 
published,  it  was  proved  that  this  multiple  Service  Access  Points  ( 
SAP  )  feature,  available  only  in  LAPD,  introduces  a  minor 
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performance  impairment  [5],  It  seems  thus  that  it  would  be  worse 
than  LAPB,  on  a  point-to-point  basis. 

In  the  same  time.  Frame  Relay,  that  uses  LAPD,  does  achieve 
comparable  performances  to  actual  packet  networks,  if  correctly 
designed.  This  technique  takes  the  most  out  of  the  new  equipments 
that  are  going  to  be  used  in  ISDN.  It  uses  simpler  mechanisms,  and 
most  of  all  leads  to  much  less  network  functions. 

I  do  not  think  that  Frame  Relay  will  provide  for  a  'super  network'. 
However,  it  is  a  way  of  using  better  quality  equipment  in  a  simpler 
way,  and  by  providing  equivalent  service  characteristics. 
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III-  Comparison  of  LA PB  and  LAPP, 

The  suggestions  we  made  in  the  previous  section  are  somewhat 
contradictory.  They  outline  that  two  different  protocols  should  be 
used  in  two  different  phases.  This  does  not  allow  for  a  smooth 
transition  from  one  to  the  other. 

Rather,  we  would  like  to  point  out  the  fact  that  two  LAPB  and  LAPD 
entities  could  'talk'  or  interoperate,  thus  simplifying  the  transition 
from  one  scenario  to  the  other.  In  [2],  R.J.  Cherukuri  proposes  to 

define  a  LAPD+  that  would  ensure  this  transition.  Let  us  first  look  at 
the  differences  and  incompatibilities  between  the  protocols. 

LAPB  was  defined  much  earlier  than  LAPD,  and  in  fact  served  as  a 
background  for  defining  the  enhanced  version  to  be  used  in  ISDN  : 
LAPD.  The  biggest  difference  in  the  functionalities  between  the  two. 
and  the  major  improvement  on  LAPD  over  LAPB  is  the  multiplexing 
capability  :  LAPD  can  handle  as  many  as  64  layer  3  entities  on  a 
single  layer  2  connection,  whereas  LAPB  usually  handles  only  one. 

However  this  does  not  enable  compatibility  between  the  two 

protocols,  since  a  LAPB  entity  communicating  with  a  LAPD  entity 
does  not  see  what  is  on  top  of  its  peer  :  there  could  be  1  or  64 

entities  on  top  of  it,  it  could  still  be  able  to  communicate. 

III.  1  Functional  Differences  Between  LAPD  and  LAPB 

Let  us  examine  the  differences  between  LAPB  and  LAPD. 

They  are  both  point  to  point  Data  Link  layer  protocols,  which  means 
that  they  essentially  perform  : 

-  error  control  on  the  frames, 

-  flow  control  between  the  two  ends, 

-  framing. 

Additionally,  LAPD  is  presented  as  a  'super  LAPB'.  performing  a 
function  that  LAPB  does  not  : 

-  multiplexing  of  packets  over  point  to  point  links. 

X25  can  be  implemented  on  top  of  both  of  them,  with  the  same 
functionalities.  One  additional  possibility,  however,  is  the 
multiplexing  of  X25  virtual  circuits  over  LAPD  frames,  as  shown 
below  : 
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I  aver  ^ 

^  1  awr  ?  w 

X25-LAPB  :  no  layer  2  multiplexing 

S-Q- 

X25-LAPD  :  layer  2  multiplexing 


This  functionality  is  possible  thanks  to  the  addressing  performed  in 
LAPD,  which  is  based  on  a  Data  Link  Connection  Identifier,  that 
uniquely  identifies  the  Data  Link  Service  Access  Point  (  DLSAP  ) 
using  the  Data  Link  Layer  services.  The  format  of  LAPB  addresses 
could  allow  such  a  scheme  but  the  operation  of  the  protocol  does  not. 
This  is  one  of  the  reasons  why  LAPD  was  recommended  as  a  layer  2 
protocol  for  the  protocol  stack  the  future  ISDN  packet  terminals  will 
use.  One  other  is  Frame  Relaying,  that  we  saw  in  a  previous  section. 

III.2  Address  Field. 

The  basic  formats  used  in  both  protocols  differ  in  the  lengths  they 
use  : 


LAPB 


LAPD 


0  CR 


1 


They  are  however  compatible  in  the  sense  that  LAPB's  E-bit.  used  for 
extendable  addresses,  is  also  used  in  LAPD,  and  LAPB  addresses  can 
be  turned  to  2  octets  addresses. 
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III. 3  Control  Field. 


The  control  fields  are  different  but  LAPB  defines  an  extended 
version  for  its  control  field  that  matches  exactly  LAPD’s  control  field 


LAPB 


LAPD 


1 

S 

U 


I 

s 

u 


III. 4  FCS. 

Both  frames  have  the  same  functional  field  decomposition.  However 
there  is  a  slight  difference  in  one  of  the  field.  FCS,  or  Frame  Check 
Sequence,  that  allows  Layer  2  error  control  : 


Flag 

Addr 

Con 

Info 

FCS 

Flag 

LAPB  allows  for  a  32  bits  FCS,  whereas  LAPD  allows  for  a  16  bits  FCS 
field  only.  This  improvement  is  due  to  the  improvement  in  reliability 
of  ISDNs  over  PSPDNs,  and  particularly  to  the  technology  and  links 
quality.  This  difference  proves  to  be  a  problem  since  each  entity 
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using  a  different  size  for  this  field  might  mix  Info  bits  with  FCS  bits 
and  vice  versa. 

We  did  not  find  any  recommendation  in  the  standard  or  any 
implementation  in  the  literature  that  allows  for  a  reduced  FCS  field 
in  LAPB. 

III. 5  Operation. 

LAPD  and  LAPB  define  two  main  operation  modes  :  acknowledged  or 
unacknowledged,  and  do  coincide  on  this  point. 

LAPD  makes  a  difference  in  the  two  ends  of  a  point  to  point 
communication,  and  differentiates  the  network  side  from  the  user 
side.  This  difference  appears  in  the  use  of  the  C/R  bit  in  the 
operation  of  the  protocol  : 


LAPD 


Function 

Direction 

C/R 

net  ->  user 

1 

Command 

user  ->  net 

0 

net  ->  user 

0 

Response 

user  ->  net 

1 

LAPB  does  not  make  any  difference  between  the  user  or  the  network 
side  :  commands  have  C/R=0,  and  responses  have  C/R=l. 

This  is  a  big  difference  between  the  two  protocols  and  the  only  way 
to  have  a  LAPD  and  a  LAPB  entities  interoperate  is  to  change  one  of 
the  protocols,  or  use  a  bridge  that  terminates  the  two  protocols  on 
each  side. 

There  is  another  big  difference  :  1-frames  are  commands  only  in 
LAPD,  whereas  they  can  be  commands  or  responses  in  LAPB  This 
would  result  in  a  LAPD  entity  resetting  the  line  if  it  received  an  I- 
frame  from  a  LAPB  entity,  intended  as  a  piggybacked 
acknowledgement,  but  taken  as  an  error  condition  by  the  LAPD 
entity.  All  other  frames  have  the  same  Command/Response  meaning 
in  the  two  sets. 
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However,  LAPB  here  defines  much  more  frames  than  LAPD  does.  In 
fact  it  contains  several  additional  frames,  most  of  them  due  to  the 
initialization  capability  offered  at  this  layer  by  LAPP.  These  are  : 

-  SIM  frame  and  its  responses  DM  (  Disconnect  Mode  ),  RD  ( 
Request  Disconnect  ),  and  RIM  (  Request  Initialization  Mode  ). 

-  TEST  frame. 

-  SREJ  frame  for  the  selective  frame  reject. 

-  UP  and  RSET  frames. 

This  does  not  prove  to  be  a  big  problem  between  the  two  protocols 

since  we  can  still  enable  the  use  of  the  frames  that  are  not 

understood. 

Also,  the  FRMR  frame,  used  in  the  frame  rejection  mechanism,  is 

never  sent  by  a  LAPD  entity,  although  understood  and  proceeded  if 
received,  and  a  SABME  is  rather  used  in  these  conditions.  This  is  not 
an  incompatibility  between  the  protocols. 

The  last  frame  that  causes  problems  is  the  XID  frame  used  by  an 
entity  to  request  identification  of,  and  some  information  about  its 

peer  entity. 

In  the  operation  of  the  protocols,  there  is  a  major  point  that  would 
not  allow  interoperation  :  LAPD  allows  an  I-frame  to  be 
retransmitted  on  timeout  conditions  (  meaning  on  an 
acknowledgement  timeout  ),  LAPB  does  not.  This  situation  could 
cause  a  LAPB  entity  to  receive  a  duplicate  frame  from  its  peer  entity. 
As  a  consequence,  LAPB  resets  the  line. 

Also,  in  LAPD,  the  Poll/Final  bit  is  set  to  1  only  in  timer  recovery 
procedures  like  acknowledgement  timeouts  ;  in  LAPB  P  can  be  set  to 
1  anytime. 

III. 6  Internal  Structure. 

Concerning  the  internal  structures,  the  differences  are  minor,  and  do 
not  affect  the  interoperability.  Can  be  outlined  : 

-  Timers  are  not  the  same. 

-  The  number  of  states  defined  for  the  operation  of  the  two 
protocols  are  different. 

-  LAPD  uses  dynamic  windowing  for  flow  control,  LAPB  uses 
sliding  fixed-size  windowing. 

-  Delays  are  slightly  different  due  to  I-frames  being  commands 
only  in  one  case,  and  commands/responses  in  the  other  (  allows 
piggybacked  ).  However,  some  studies  showed  that  the 
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difference  is  noi  important,  and  using  mechanism  as 
multirejects  can  significallv  improve  the  performances  [1]. 

III. 7  Some  Interoperating  Scenarios  and  a  Suggestion. 

In  order  to  have  LAPB  and  LAPD  overcome  their  difference,  there 
are  3  scenarios  : 

[a]  modify  LAPB  so  that  it  operates  with  LAPD. 

[b]  modify  LAPD  so  that  it  operates  with  LAPB. 

[c]  define  a  LAPD+  that  makes  the  link  between  the  two. 

Scenario  [c]  is  described  in  [2]  and  is  useful  in  a  LAN-ISDN 
interconnection  environment.  Our  purpose  is  to  study  the  impact  on 
X25  terminals  access  to  ISDN  of  a  change  in  the  protocols. 

As  defined  in  [3],  two  possible  means  to  provide  packet  services  : 
over  B  or  D  channel,  and  two  phases  in  integration.  In  the  first  phase, 
access  is  only  over  B-channel.  with  an  ISDN  circuit  going  from  the 
user  to  a  PSPDN  access  node.  In  the  second  phase,  ISDN  has  some 
packet  handling  facilities,  and  takes  care  of  the  packets  itself,  with  a 
circuit  going  only  from  the  user  to  the  ISDN  packet  handler. 

The  problem  is  that  when  accessing  the  packet  services,  the  user 
either  uses  the  D-channel  as  a  packet-channel,  or  establishes  a 
connection  between  the  user  and  an  eventual  packet  handler.  This 
aspect  cannot  be  changed,  but  by  modifying  the  protocols,  we  can 
allow  X25  terminals  to  use  their  own  protocol  to  set  up  a  circuit  in 
ISDN  : 


L 

A 

T 

terminal 

Conversion 

A 

P 

Rate  adaption 

P 

B 

D 

By  matching  LAPB/D,  the  TA  functions  become  simpler.  Setting  up  a 
circuit  over  the  D-channel  can  be  made  by  using  X25-LAPB  of  the 
terminal.  However  one  still  cannot  use  X25  directly  over  the  B- 
channel  without  having  it  set  up  using  the  1.451  procedures. 

Now  the  choice  between  ja]  or  [b]  would  consider  the  following 
factors  : 


-  X25  is  a  widely  used  protocol,  meaning  that  a  lot  of  terminals 
and  applications  use  this  stack  for  their  communication. 
Modifying  LAPB  is  equivalent  to  modify  X25. 
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-  LAPD  is  noi  as  widely  implemented  and  used. 

-  Considering  the  few  modifications,  concerning  C/R  bit  use,  I- 
frames  allowed  as  responses  or  not,  retransmission  of  1-frames, 
modifying  LAPD  seems  technically  simpler. 

We  suggest  thus  that  LAPD  be  modified  in  order  to  : 

-  provide  symmetrical  use  of  the  C/R  bit.  This  drives  to  no 
more  distincting  the  user  side  from  the  network  side. 

-  Not  allow  I-frames  to  be  retransmitted  on  timeouts. 

-  Allow  for  piggybacked  acknowledgements. 

These  few  changes  allow  for  interoperation,  and  use  of  LAPB  in  call 
control  over  the  D-channel,  uniformizing  the  use  of  packet  services  in 
ISDN. 


IV-  Summary  of  the  Arguments. 

In  the  previous  paragraphs,  we  stated  the  following  : 

-  On  a  functional  basis,  LAPB  and  LAPD  are  different  in  that 
LAPD  provides  multiplexing  of  data  link  connections  on  one 
media. 

-  On  a  protocol  basis,  few  differences  appear,  and  the  two 
protocols  can  even  interoperate  if  a  few  changes  are  made. 

-  On  whether  to  use  LAPB  or  LAPD  over  the  B  channel  for 
packet  access,  the  uniformity  arguments  were  raised  for  each 
of  them  :  LAPB  makes  the  end  to  end  connection  more  uniform, 
whereas  LAPD  makes  the  user's  access  more  uniform  by  using 
only  one  data  link  layer  entity  on  the  user’s  side. 

-  An  additional  point  was  made  for  LAPD  when  the  use  of 
frame  relay  technology  is  foreseen  in  the  network.  Frame  relay 
uses  LAPD  as  an  edge  terminating  protocol. 

In  the  coming  discussion,  we  would  like  to  look  closer  at  the  validity 
of  these  arguments  : 

-  the  implementability  of  a  common  data  link  layer  on  the 
user's  equipment  for  both  D  and  B  accesses  has  to  be  examined 
closely. 

-  Frame  relay,  its  concepts,  assumptions  and  mechanisms  will 
be  criticized  in  order  to  contribute  to  the  raising  question  of 
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whether  or  not  implementing  it  is  worth  it.  More  particular!)’, 
we  would  like  to  look  closer  at  congestion  control  and  flow 
control,  which  are  big  issues  in  frame  relay  networks. 

V-  The  Common  Data  Link  Layer. 

V.l  Input/Output  :  the  USART. 

At  the  physical  level  of  any  communication,  one  finds  a  port  and  its 
controller  for  the  transmission  (see  Fig.  1).  The  current  name  for  the 
unit  is  Universal  Asynchronous  Receiver/Transmitter  (UART)  or 
Universal  Synchronous/Asynchronous  Receiver/Transmitter 
(USART). 

A  port  is  generally  a  microprocessor,  with  its  own  clock,  its  memory 
and  registers,  and  a  processing  unit.  The  intelligence  of  a  port  is 

highly  variable,  and  can  include  very  few  to  a  lot  of  functionalities. 

Currently,  it  includes  up  to  layer  2,  or  part  of  layer  2,  functionality. 

Concerning  ISDN,  the  interface  is  built  onto  a  card  that  plugs  into  a 
computer.  LAPD  is  implemented  in  the  hardware,  since  simulations 
proved  that  a  software  implementation  is  much  too  slow  for  a  real 
application  purpose.  Our  purpose  is  to  study  whether  or  not  a 

common  utilization  of  the  LAPD  unit  by  the  network  layer  softwares 
of  both  D  and  B  channels  is  possible. 
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V.2  General  ISDN  Imerface. 

The  structure  of  the  ISDN  interface  on  the  user's  side  is  described  in 
16]  : 


Applications 

Network 

X25 

Data  link 

LAPD 

LAPB 

Physical 

Layer  1  1.430,  1.431 

D  channel 

B  channel 

The  actual  physical  layer  is  1.430,  1.431.  The  data  link  layer  is  LAPB 
or  LAPD,  and  the  layer  3  is  1.451,  X25,  .... 

If  LAPD  was  to  be  used  only,  it  would  replace  LAPB  on  the  B  channel. 
The  new  architecture  is  detailed  in  the  next  section. 


V.3  Interface  Architecture. 


The  ISDN  interface  for  packet  services  will  follow  the  structure 
above,  and  implement  the  required  stack  of  protocols  on  a  card  that 
would  have  the  following  architecture  : 


USART 
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The  USART  will  implement  up  to  layer  2  and.  embed  the  LAPD  entity 

At  the  layer  3  we  will  be  using  X25  on  the  B  channel  in  the  circuit 

mode  (or  minimum  integration  scenario),  and  also  on  the  D  channel 

in  the  packet  mode  (or  maximum  integration  scenario),  and  the  call 
control  entity. 

Let  us  suppose  now  that  there  is  a  single  layer  2  module  that  serves 
both  layer  3  modules  X25  and  1.451. 

From  the  LAPD  definition,  we  know  that  the  protocol  distinguishes 
between  the  layer  3  entities  it  serves  by  looking  at  the  Service 

Access  Point  Identifier,  or  SAPI.  Depending  on  the  values  of  this 
number,  different  types  of  connections  are  made  up  : 

SAPI=0  is  for  Signaling  Information  or  Call  Control  procedures. 
SAPI=1  relates  to  packet  mode  connections  over  the  D  channel 
with  1.451.  This  service  is  referred  to  as  Fast  Packet  Switching. 
SAPI  =  16  designates  X25  level  3  communications  or  packet 
accesses  on  the  B  channel. 

SAPI=63  is  reserved  for  management  communication. 

From  these  values,  it  turns  out  that  a  single  LAPD  module  cannot 
serve  layer  3  entities  for  accesses  on  both  B  and  D  channel.  A  typical 
malfunction  would  occur  like  in  the  case  below  : 

The  D  channel  can  carry  control  information,  that  is  directed  to  the 
1.451  layer  3  entity  with  SAPI=0.  It  also  sends  or  receives  packeted 
information  through  SAPI  1  and  16.  If  the  same  LAPD  module  takes 
care  of  both  B  and  D  channel  types,  it  will  not  be  able  to  differentiate 
the  packets  that  are  directed  to  B  channel  layer  3  packet  handling 
entities  from  the  ones  that  are  directed  to  D  channel  layer  3  packet 
handling  entities. 
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As  shown  in  ihe  picture,  the  same  SAP]  is  carried  over  two  different 
’ypes  of  communication.  It  is  thus  impossible  for  a  single  LAPD 
entity  to  service  an  X25  D  channel  module  and  an  X25  B  channel 
module. 

Such  a  differentiation  would  be  possible  by  renumbering  the  entities 
and  assign  different  numbers  to  entities  that  refer  to  B  channel 
communications  or  to  the  D  channel  communications.  For  example, 
SAPI=16  could  be  X25  D  channel  layer  3  entity,  whereas  SAPI=17 
would  represent  an  X25  B  channel  entity.  This  has  not  been  done  by 
the  standards  committees  ;  I  suppose  it  is  because  LAPD  is  designed 
to  be  the  data  link  layer  of  the  D  channel. 

V.4  Implications. 

In  the  previous  paragraphs,  we  identified  a  uniform  user  access  as 
being  an  advantage  for  LAPD  over  LAPB.  It  appears  that  a  single 

entity  cannot  be  used  for  performing  the  data  link  layer  functionality 
commonly  to  D  and  B  channels. 

This  is  due  to  the  early  definition  of  LAPD  as  being  the  data  link 
layer  of  the  D  channel,  and  probably  to  the  fact  that  the  control 

software  for  D  channel  communications  interfaces  with  the  D  channel 
at  the  data  link  layer,  whereas  the  control  software  for  B  channel 
communications  interfaces  with  the  B  channel  at  the  physical  layer. 

In  discussing  this  possibility,  another  point  arose  against  the  use  of  a 
LAPD  entity  as  data  link  layer  of  an  X25  module  on  the  B  channel  : 

-  multiplexing  will  not  be  used  as  it  is  defined  in  LAPD,  since 

the  data  link  will  only  carry  user  information  from  a  single 

layer  3  entity  that  already  performs  logical  channel 

multiplexing. 

-  Using  a  LAPD  entity  is  finally  equivalent  to  use  only  the 
SAPI=16  data  link  connection,  since  on  the  B  channel  there  will 
not  be  any  entity  with  SAPI=0  (  signaling  ),  SAPI  =  1  (fast 
packet)  or  SAPI=63  (management). 

VI-  Frame  Relay. 

Vi.l  Principles. 

The  idea  behind  frame  relay  is  to  reduce  the  amount  of  processing 
performed  in  the  network's  nodes  on  the  user’s  data.  This  is  achieved 
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by  using  only  a  subset  of  the  data  link,  layer's  functions  in  the 
intermediate  nodes,  and  terminating  the  data  link  connection  on  an 
end-to-end  basis,  instead  of  a  point-to-point  basis  (see  Fig.  from  { S 1 ) . 


end 


nod 


Frame  relay  network 


intermediate  node 


/ 

Data  link 
sub-layer 


I  performs 


Physical 

layer 


Frame  delimiting, 
alignment,  transparency 
Frame  muxing/demuxing 
Length  check 
Detection  of  errors 


Procedure 

performs^ 

layer 

Data  link 

sub-layer 

Physical 

layer 

Mode  selection 

Maintaining  sequence  counts 

Acks 

Error  recovery 
Flow  control 
XID  exchange 


We  talked  about  frame  relay  in  an  earlier  paragraph,  but  some 
points  were  not  addressed  in  our  discussion  :  congestion  and  flow 
control,  particularly. 

This  problem  is  raised  in  many  papers  in  the  literature,  and  it  seems 
that  a  lot  of  people  try  to  address  what  is  probably  the  biggest 
concern  in  dealing  with  frame  relay  networks.  The  next  table 
establishes  a  comparative  study  of  the  congestion  control 
mechanisms  found  in  X25  and  frame  relay  networks. 


X25 

Frame  relay 

Link  by  link 

RR  frame  of  LAPB 
(choke) 

-  priority  classes  and 
separate  queues  at 

DL  sublayer. 

-  stop  message,  drop 
frames. 
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End  to  end 

-  choke  packet 

-  transport  credits 

-  RR  frame  of  LAPD 

-  adaptive  window' 

Entry  to  exit 

-  entry  tickets 

same  as  link  by  link 

As  a  summary  on  congestion  control  and  a  concluding  statement  on 
it,  we  would  like  to  point  out  the  general  attitude  about  congestion 
and  flow  control  in  frame  relay  networks  : 

-  it  is  a  much  more  complex  to  solve  in  frame  relay  networks 
than  in  regular  packet  networks,  because  FR  nets  are  much 
more  sensitive  to  flow  control  problems.  Congestion  is  solved 
by  droping  frames,  whereas  X25  uses  its  data  link  layer  flow 
control  to  handle  the  problem  i_n  the  network. 

-  Every  solution  reports  the  flow  control  load  on  the  user, 
because  the  network  does  not  handle  anymore  the  extra 
overload,  and  does  not  perform  any  other  flow'  control  function 
than  throwing  overflow  frames  away. 

Error  control  is  also  an  aspect  that  is  really  different  from  classical 
networks  to  frame  relay.  The  main  difference  occurs  on  a  point  to 
point  error  control  that  frame  relay  does  not  perform  anymore. 
Frame  relay  just  discards  those  frames  that  the  sub  layer  detects  as 
being  in  error,  letting  the  end  user  time  out  on  the  loss,  whereas  in 
an  X25  network,  the  receiving  node  would  ask  the  previous  node  to 
repeat  its  transmission.  In  all  cases  frame  relay  networks  time  out  on 
the  transmitter's  side,  w-hereas  in  X25  ne*‘  orks,  nodes  send  negative 
acks  to  each  other  along  the  path,  thus  not  timing  out  any  time  a  loss 
or  an  error  occur.  The  loss  is  considerable  w'hen  errors  occur  in  FR 
nets  : 

if  we  assume  a  10  hops  path  between  tw'o  users. 


user  1 

node 

node) 

h  ode 


kiscr  2 


X25  timer  =  point  to  point  delay  +  £ 

FR  timer  =  10  point  to  point  delay  +  lOx  £ 

On  a  per  packet  point  of  view',  the  time  before  recovery  might  be  10 
times  larger  in  the  case  of  a  FR  network.  In  most  of  the  cases,  it  is 
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even  more  because  the  next  node  in  the  network  will  ask  ior  a 
retransmission,  that  will  occur  at  once. 

However,  the  overhead  of  X25  processing  is  someiimes  estimated  to 
10  times  longer  than  the  regular  FR  processing  [9]. 

Another  point  for  X25  is  that  the  window  will  probably  be  larger  in 
FR  than  in  X25,  because  silences  have  to  be  as  short  as  possible 
before  receiving  acks.  A  loss  would  thus  cause  more  backup,  and 
more  frames  to  be  retransmitted. 

A  point  for  FR  is  however  that  routing  will  be  much  faster,  because 
performed  earlier  in  the  processing  (one  layer  below),  and  so  is 
multiplexing. 

As  a  summary,  FR  nets  are  much  more  sensitive  to  environment  with 
errors,  but  a  basic  assumption  to  their  implementation  is  that 
equipment  used  make  less  errors. 
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Part  2  :  Signaling  System  7 
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I-  Introduction, 

Signaling  System  n.7  (SS7)  is  the  protocol  used  in  the  Common 
Channel  Signaling  Network  (CCSN)  that  implements  the  signaling 
function  in  ISDN.  This  protocol  allows  for  transmitting  signaling 
messages  between  Signaling  Points  (  SP  )  and  Signaling  Transfer 
Points  (  STP  ).  It  is  an  internal  protocol  to  the  network.  In  this  part, 
we  will  look  at  the  user  involvement  in  signaling,  and  at  the  impact 
on  the  user  and  the  network  of  'delivering'  SS7  directly  to  the  user. 

In  a  first  part,  a  description  of  SS7  and  CCS N  is  provided,  and  the 
interaction  with  the  actual  user  is  also  provided. 

In  a  second  part,  we  come  up  with  a  description  of  what  would  a  full 
access  by  the  user  to  SS7  look  like  benefits,  requirements, 
constraints  and  new  architecture.  After  deriving  the  side  'effects’,  a 
new  proposition  is  made  that  leads  to  defining  new  services  for  the 
user. 


II-  Signaling  Svstem  7  :  an  overview. 

II. 1  Basic  concepts  of  a  Common  Channel  Signaling  Approach. 

Back  in  the  telephone  golden  ages,  the  entire  public  network  was 
dedicated  to  telephony,  and  remained  so  until  the  computer  brought 
this  need  for  exchanging  data  between  subscribers,  and  most  of  all 
the  digital  concept  that  would  change  the  technology  forever. 

In  every  communication,  there  is  a  need  for  control  signal.  In  fact,  no 
communication  can  ever  take  place  without  control  :  information  has 
to  be  coded  in  a  way  that  both  communicating  entities  understand, 
and  there  has  to  be  some  signals  between  them  saying  that  they  are 
addressing  each  other,  talking  to  each  other,  and  ending  a 

communication . 

In  the  telephone  world  these  signals  are  :  dialing,  dial  processing, 

ringing,  busy,  answering,  ...  signals.  In  the  early  ages,  these  signals 
were  exchanged  within  the  bandwidth  of  the  transmitted  signal  (  the 
human  voice  ).  This  technique  is  called  ln-B3nd  signaling,  and 

represented  in  Figure  3.  Another  technique  for  signaling  is  called 
Out-of-Band,  and  signifies  that  the  signals  are  not  carried  at  the  same 
frequencies  than  the  voice  signal,  as  shown  in  Figure  1.  These  two 

modes  refer  to  an  InChannel  signaling,  meaning  that  the  same  trunk 
is  used  for  signals  and  signaling.  This  presents  the  following 

drawbacks 


Special  Problems 


-  The  information  rate  is  limited,  due'  to  the  two  overhead  of 
control  on  the  information  channel. 

-  The  delays  in  establishing  a  connection  are  large,  and  need  to 
be  reduced. 

These  problems  can  be  addressed  using  common  channel  signaling, 
as  illustrated  in  Figure  1.  Here  offices  exchange  digital  control  signals 
over  dedicated  channels.  This  gives  a  more  powerful  signaling 
possibility,  optimizes  the  service  delays,  the  bandwidth  utilization, 
and  improves  considerably  the  network  management  applications,  as 
we  shall  see  later. 


Common  channel  signaling  technique 


In-channc!  signaling  icchniquc 


SIG  =  user  signal 
CON  =  control  signaling 


Figure  1  :  signaling  techniques 
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Common  Channel  Signaling  (  CCS  )  allows  us  to  separate  information 
and  control.  thus  having  transparent  digital  information 
communication  over  the  trunks. 


II. 2  Protocol  Architecture. 

The  architecture  of  SS7  is  shown  in  Figure  2  and  is  composed  of  : 


OSI 


Figure  2  :  SS7  archjtec ' ure  [  1  ] 

-  Message  Transfer  Part,  or  MTP  :  in  charge  to  provide  with  a 
connection  less  transmission  of  control  signals.  It  provides  a 
datagram  service  for  the  exchange  over  the  signaling  links. 

-  Signaling  Connection  Control  Part,  or  SCCP  :  SS7  will  have  to 
provide  with  connection-oriented  communications,  this  one  of 
the  roles  of  this  part.  It  also  provides  with  a  full  global 
addressing  that  complements  MTP  addressing  (  in  fact  MTP 
allows  only  to  address  the  STPs  or  SPs  on  a  14  to  24  bn 
addresses  base,  which  is  not  enough  for  process  and  user 
addressing  ). 
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-  ISDN  U  ser  Pan,  or  1SUP.  provides  call-related  services  for 

ISDN. 

-  Telephone  User  Part,  or  TUP.  provides  circuit-related  services 
for  telephone  call  control. 

-  Operations.  Administration,  and  Maintenance,  or  OAM,  covers 
the  network  management  functions. 

II. 3  Function  in  the  Network. 

SS7  is  used  for  interoffice  signaling.  This  means  that  it  is  an  internal 
protocol  to  ISDN,  and  is  used  for  transmitting  control  signals  between 
two  ISDN-network  nodes. 

The  CCSN  is  one  of  the  logical  networks  involved  in  ISDN.  The 
principle  behind  ISDN  is  to  offer  a  general  interface  for  all  services, 
but  the  network  is  not  designed  to  implement  actually  all  these 
services.  This  is  not  realizable,  because  there  are  too  many  services 
that  require  too  many  different  performances.  Rather.  ISDN  will 
implement  the  general  architecture  below. 


ISDN 


interface 


The  CCSN,  or  signaling  network,  can  itself  rely  on  another  physical 
network,  and  just  add  its  protocol  architecture  and  functionalities. 
The  figure  could  actually  be  misunderstood  in  the  sense  that  the  user 
does  not  directly  issue  signals  that  travel  through  the  signaling 
network.  Whatever  he  issues  is  considered  as  being  information  by 
the  interface.  Even  user-to-user  control  signaling  travels  through  the 
data  networks,  and  not  the  control  network. 
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What  is  the  user  involvement  in  the  use  of  SS7  ?.  We  would  be 
tempted  to  say  none.  The  only  control  interface  between  the  user 
and  the  network  is  the  User-Network  Interface,  defined  in  the  1.4 
series  as  1.430,  I.44x  and  I.45x  of  the  CC1TT.  There  is  an  interaction 
between  control  signals  that  the  user  accesses  through  these 
protocols  and  some  parts  of  SS7,  the  ISUP.  Actually,  ISUP  is  no  more 
than  I.  451  with  additional  functions  and  features,  and  there  is  a 
direct  mapping  between  them. 

However,  there  are  more  and  more  applications  that  require  a  bigger 
involvement  of  the  user  in  the  public  network  resources  control. 
Among  these,  a  LAN  to  LAN  connection  through  ISDN,  using  its 
flexibility  and  power.  Such  users  want  also  some  management 
services.  We  will  take  a  look  at  these  applications  in  the  next  part. 


Ill-  Delivering  SS7  to  the  User. 

III.l  Uses  of  SS7. 

Clearly,  there  are  a  lot  of  new  services  that  are  proposed  to  the  user 

through  ISDN.  It  first  integrates  all  the  different  accesses  to  different 

networks  in  a  single  interface. 

SSI  is  the  way  of  controlling  the  public  network.  Giving  it  to  the  user 

will  have  to  take  this  parameter  into  account  :  if  all  users  have 

control  over  a  pool  of  resources  and  this  control  is  not  organized  or 
regulated,  the  efficiency  of  the  network  resources,  and  eventually 
the  service  offered  to  the  user,  are  going  to  drown  drastically.  It  is 
well  known  that  centralized  controls  generally  ensure  a  strict  use  of 
the  resources,  however  it  is  not  fault  tolerant,  and  flexible. 
Distributed  control  is  preferable,  and  our  goal  will  be  to  obtain  some 
sort  of  distributed  control  of  the  resources  of  the  public  network,  by 
designing  a  user  control  policy. 

It  seems  that  the  user  applications  that  require  a  real  control  of  the 
public  network  are  rather  ’big',  and  include  some  data 
communications  applications. 

A  good  example  of  this  are  the  Virtual  Private  Networks,  in  which  a 
user  has  access  to  resources  of  the  public  network,  and  uses  them  as 
if  they  where  part  of  a  private  network  he  would  possess.  This  kind 
of  application  is  generally  software  defined,  and  the  user  needs  some 

way  of  managing  data  bases  for  configuration,  accounting . 

A  second  example  is  more  oriented  towards  telephony,  and  is 
referred  to  as  Feature  Networking  in  [2].  The  user  here  is  generally  a 
corporation  that  has  a  set  of  agencies  throughout  the  country  It 
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wants  to  be  able  to  interconnect,  for  telephone  as  well  as  for  data 
communications,  its  agencies  and  their  workers  using  an  internal, 
simplified  addressing  scheme.  The  result  is  that  several  locations 
appear  as  one  for  communications,  and  they  are  transparent  across 
geographic  locations.  Such  services  include  location  code  dialing 
plans,  centralized  numbering  plans,  ... 

A  set  of  general  requirements  from  the  users,  independent  of  the 
applications  has  been  identified  in  (2],  as  : 

-  interactive  bandwidth  capacity  modification. 

-  creation,  modification  and  storage  of  different  network 
configurations  to  be  implemented  at  different  times. 

-  creation  of  a  schedule  that  go  with. 

-  network  monitoring  in  real  time. 

-  accounting  for  each  user  individually. 

Finally,  we  can  note  that  the  general  idea  of  user  control  over  the 
network  is  a  full  ability  to  manage  their  resources,  including  Fault. 
Configuration,  Accounting,  Performance  and  Security,  the  five 
functions  defined  in  OSI  management.  We  will  aim  at  providing  a 
distributed  management  scheme  that  will  include  delivering  SS7  to 
the  user,  and  providing  a  control  scheme  that  still  allows  for  an 
efficient  share  by  the  users  of  the  pool  of  public  resources. 

III. 2  A  Virtual  Public  Network, 

In  today's  ISDN,  the  user  has  access  to  control  functions  through 
1.451,  or  the  D-channel  protocol  for  signaling,  as  showm  in  Figure  3.  It 
is  called  the  network  interface  and  is  basically  a  subset  of  1SUP.  the 
ISDN  User  Part  we  already  saw. 
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USER  SIDE  |  NETWORK  SIDE 


l  signaling 

LE 

SS7  signaling 

LE=  Local  Exchange 


Figure  3  :  correspondence  between  1. 451  and  SS7 

The  new  approach  that  can  be  envisaged  is  based  on  the  delivery  to 
the  user  of  SS7  as  a  whole,  as  shown  in  Figure  4.  It  provides  hint 
with  the  same  control  signals  as  before,  plus  some  capability  for 
managing  the  public  resources.  In  order  to  still  have  an  efficient  use 
of  the  network,  the  new  services  are  provided  as  requests,  instead  of 
commands.  Basically,  SS7  is  now  divided  in  two  parts  :  the  first  one 
concerned  with  call  control  (  or  all  parts  up  to  level  3  in  Figure  2  ) 
procedures  is  provided  as  commands,  as  it  was  previously.  A 
telephone  user  will  issue  a  call  in  the  exact  same  way. 

User  side  |  Network  side 


SS7  signaling 

LE 

SS7  signaling 

Figure  4  :  a  new  approach. 

The  new  potential  is  now  for  users  with  more  developed  applications, 
using  PBXs,  MUXs,  ....  who  will  be  able  to  monitor  the  public  part  ot 
their  network,  as  if  it  effectively  belonged  to  them.  Figure  5  sho^s 
some  of  these  possible  customers. 

They  can  dispose  of  the  whole  SS7  parts,  and  thus  send  commands 
for  reconfigure  their  public  lines,  modify  their  associated  bandwidth, 
ask  for  a  momentarily  new  service.  This  improves  the  service 
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flexibility,  and  eases  the  user's  network  evolution.  It  will  simplifies 
the  access  to  the  control  procedures  on  the  user's  side  and  simplifies 
the  functionalities  previously  needed  in  the  user's  interface  to  map 
the  user’s  and  the  network's  protocols.  It  modifies  also  considerably 
the  management  architecture,  as  we  shall  see  in  the  next  paragraph. 
However  this  raises  a  big  problem  of  security  for  the  network 
provider  :  if  it  allows  all  users  to  command  the  network  components, 
it  needs  an  authority  for  solving  the  possible  conflicts,  and 
controlling  that  the  modification  asked  for  by  the  user  will  not  drown 
the  network  service. 

This  problem  is  solved  by  adding  a  network  controller.  This  entity  is 
represented  on  Figure  5,  and  seems  to  be  a  central  point  of  the 
network.  However,  since  the  control  is  to  be  distributed  among  the 
users  in  customer  control  entities,  we  recommend  a  geographical!)'  or 
functionally  distributed  network  controller.  The  architecture  to  be 
adopted  depends  on  the  architecture  of  the  network.  For  example,  ir 
the  North  American  telephone  network,  a  good  architecture  would 
consist  of  having  a  network  controller  responsible  for  allocating  the 
resources  to  users  on  a  per-area-code  basis.  This  means  that  a  user 
submits  a  request  for,  say,  reconfiguring  half  of  its  links.  This  request 
goes  to  the  local  network  controller,  that  allows  this  manipulation  by 
sending  the  appropriate  command  to  the  appropriate  switches,  or 
disables  it. 
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Figure  5  :  an  example  of  use  of  SSI.  (31 

As  one  can  see  on  the  picture,  each  user  has  a  controller,  that  sends 
commands  to  the  network  controller,  but  only  the  network  controller 
sends  commands  to  the  network  resources.  This  allows  him  to  check 
for  the  user's  requests. 

III. 3  Implications. 

The  first  implication  is  on  SS7.  It  has  to  be  slightly  modified  as  to 
allow  for  a  command-response  operation  mode. 

The  second  and  more  important  one  is  on  the  network  management 
point  of  view.  Figure  6  shows  the  architectural  difference  in 
providing  the  user  with  SSI. 
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User  side  Network  side  User  side 


User  access  and  management  before 


User 


Network 


U  ser 


User  access  and  management  with  SS7 


Figure  6  :  difference  in  network  management  view 

With  SS7,  the  control  becomes  shared,  and  the  user  has  practically 
the  same  role  as  any  other  administrative  entity  in  the  network,  see 
Figure  7. 
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This  determines  a 
user  access  to  the 


Figure  7  :  difference  in  network  management 

This  has  to  be  done  under  the  following  constraints  : 

-  There  has  to  be  a  control  entity  in  the  network  so  that  the 
users  do  not  overuse  the  resources  in  a  sense  that  would  cause 
performances,  and  other  users  services,  to  decrease. 

The  FCAPS  defined  in  network  management  become 
integrated,  the  service  has  also  to  be  evaluated  on  a  per-change 
basis,  per-use  basis. 

-  There  has  to  be  some  bounds  to  the  possibilities  offered  to 
the  users  to  manage  the  public  network.  These  can  be 
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determined  by  contract,  and  used  during  negotiation  between 
the  user's  control  entity  and  the  network  controller. 

-  Priority  has  to  be  given  to  the  network  controller  messages  in 
order  to  be  able  to  monitor  the  network  in  all  cases. 

-  Priority  has  also  to  be  given  for  normal  control  messages, 
related  to  call  control,  over  those  new  messages. 


IV-  Another _ Slots  gy, 

IV.  1  Critique  of  the  Previous  Approach. 

The  virtual  public  network  approach  sounds  ideal  to  users,  but  it  will 
probably  produce  a  conflictual  situation  when  applied  to  such  a 
general  network  as  ISDN,  which  supposedly  offers  all  services.  For 
example,  telephone  users  should  not  be  given  the  opportunity  to 
control  the  network,  whereas  ISDN  interconnection  of  LANs  should. 

All  the  users  transmit  requests  to  a  network  controller,  in  charge 
with  controlling  the  validity  of  the  requests,  and  their  applicability  to 
the  actual  resources.  The  conflict  arises  from  the  situation  where  two 
requests  arrive  and  are  incompatible  :  for  example,  two  users  could 
ask  for  the  allocation  of  the  same  equipment. 

A  practical  solution  is  very  difficult  to  find  in  these  conditions,  and  in 
fact  the  decision  the  network  controller  would  have  to  do  would  be 
unfair,  or  undeterministic. 

Furthermore,  there  are  quite  a  set  of  drawbacks  in  providing  all 
users  with  the  possibility  to  control  the  network  : 

-  The  network  becomes  very  complicated,  because  the  control 
comes  from  all  the  users. 

-  Congestion  problems  may  arise  that  are  not  expected,  and 
tear  down  the  network  performances,  or  even  prevent  a 
normal  operation. 

-  Delay  and  availability  become  critical  on  the  Common  Channel 
Signaling  Network,  where  the  users'  requests  are  carried  out. 

-  Users  with  simple  equipments,  not  requiring  elaborate 
management  functions  like  telephones,  fax  machines,  videotex 

terminals .  do  not  need  these  elaborate  functions  from  ISUP. 

SCCP . 

-  The  burden  of  buying  a  full  stack  for  managing  the  public 
equipments  would  not  be  negligible,  both  in  cost  and  time. 
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IV. 2  Management  is  the  Main  Thing. 

We  identified  the  management  goals  as  being  the  only  functions  the 
users  are  interested  in  in  controlling  the  network.  Taking  the  critique 
into  account,  a  more  implementable  solution  is  possible. 

It  is  based  on  reducing  the  number  of  users  that  access  the  public 
network  control  services.  The  one  that  will  be  offered  these  services 
will  pay  an  extra  amount,  and  this  should  make  them  affordable  for 
only  LAN  to  LAN  applications.  Those  who  have  LANs,  or  large 
equipments  like  PBXs,  interconnected  through  ISDN  will  be  able  to 
control  the  public  part  of  their  network. 

The  new  approach  consists  of  only  providing  the  user  with  the 
management  functionality  of  SS7,  equivalent  to  the  OA&M 

component,  an  application  layer  functionality.  Providing  the  user 
with  only  one  part  of  SS7  reduces  the  additional  time  and  money  cost 
of  adding  parts  to  the  user  interface. 

This  module  has  to  communicate  with  the  public  network 
management  entities.  This  can  be  achieved  through  the  existing 

User-Network  Interface  : 


O 

A 

M 


User-Network 

Interface 


Layer  7 


Layers  4-6 


Layers  1-3 


In  any  network,  there  is  an  entity  that  controls  the  equipments, 
either  central  or  distributed.  We  will  refer  later  to  this  entity  as  the 
Network  Management  Center  (  NMC  ).  The  user  will  communicate 
with  it  for  all  his  management  problems  concerning  the  public 
resources,  sending  requests  and  receiving  responses.  The  NMC  allows, 
just  like  the  Network  Controller  of  the  previous  approach,  some 
control  over  users'  commands  to  the  network's  equipments. 
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This  is  a  less  complicated  structure  than  the  first  solution,  and  more 
flexible  in  terms  of  who  will  be  offered  management  services. 

A  problem  still  remains  to  be  solved.  Let  us  imagine  we  have  an 
OA&M  module,  that  allows  us  to  control  a  digital  cross  connect  for 
example.  We  do  not  want  to  know'  what  the  local  NMC’s  address  is  for 
sending  a  command.  What  we  want  is  to  be  able  to  use  the  OA&M 
format  over  the  D  channel,  and  that  the  commands  go  by  themselves 
to  the  NMC  responsible  for  our  requests.  On  the  other  hand,  a  carrier 
does  not  want  to  provide  the  user  with  physical  addresses  in  the 
network,  for  example  the  local  NMC,  for  obvious  security  and  traffic 
control  reasons. 

To  our  mind,  the  solution  is  to  define  a  special  DLCI  for  the  OA&M 
communication  exclusively.  Any  active  OA&M  would  send  anv 
request  on  the  D  channel  with  a  predefined  Data  Link  Connection 
Identifier  (For  the  moment  0,  16  and  63  are  defined  and  used).  The 
communication  on  the  D  channel  would  follow  the  path  below  : 


_  ISUP,  TUP,  SCCP,  MTP  traffic 

_  _  OA&M  traffic 


NMC  is  defined  as  being  an  SP,  or  Signaling  Point,  generating 
signaling  traffic,  whereas  the  Signaling  Transfer  Point  STP  just  routes 
the  signaling  traffic. 

The  routing  at  the  initiating  SP  is  made  on  the  DLCI  number.  Users 
requests  end  at  the  NMC,  that  answers  to  the  users,  communicate 
information  and  initiate  commands  to  the  equipments  according  to 
the  requests. 

-  15  - 


Spcnal  Problems 


IV. 3  Security  Issues. 

The  main  problem  behind  providing  the  user  with  a  way  to  control 
the  network  is  security.  Public  networks  are  stable  and  robust  in  the 
sense  that  they  can  handle  any  normal  user  load  with  the  same 
performances,  and  extra  load  with  a  small  degradation.  They  do  not 
fail  in  normal  conditions.  The  main  interest  in  providing  the  new 
services  is  to  guarantee  no  robustness  alteration.  The  user  must  not 
be  able  to  create  failure  conditions,  by  monopolizing  all  equipments 
in  a  zone  for  example,  and  the  commands  issued  have  to  keep  the 
network  secure. 

In  order  to  ensure  this,  the  following  steps  should  first  be  followed  : 

-  Services  should  be  categorized,  and  contracted  by  categories. 
A  contract  number  will  be  exchanged  at  the  first  access 
between  the  user  of  the  management  services  and  the  NMC. 
along  with  any  pertinent  user  information,  in  order  to  ensure 
access  control. 

The  communication  with  the  NMC  in  a  Request/Command  order 
should  be  slower  from  the  user's  side  than  a  direct  access,  but  it 
ensures  that  some  entity  in  the  network  is  acting  between  users  and 
equipments  and  checks  and  ensures  their  function. 

Conclusion 

In  this  document,  we  examined  the  possibility  to  deliver  SS7  to  the 
user.  It  appears  clearly  that  there  is  a  demand  for  such  services  in 
the  user  applications. 

The  main  application  that  can  be  made  of  this  service  is  Network 
Management.  The  user  can  control  and  monitor  some  parts  of  the 
public  network,  which  is  a  problem  that  the  actual  carriers  will  have 
to  address. 

The  way  it  could  be  solved  is  by  adding  a  control  entity,  to  the 
already  existing  Management  Center  for  example,  and  to  deliver 
classes  of  management  services  to  the  user,  with  quality  and  contract 
negotiation. 

However  we  suggest  that  OA&M  be  delivered  to  the  user,  this  can  be 
reexamined  when  the  draft  documents  specifying  the  functions 
available  in  this  module  will  have  been  produced. 
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Experimental  Facility  —  Phase  1 

(For  FamiliariTation  and  Instrument  Development) 


Experimental  Facility  —  Phase  2 

(For  Flexible  Interconnection  and  Central  Office  Access) 


Experimental  Facility  —  Phase  3 

(For  Flexible  Interconnection  and  Primary  Rale  Access) 


Experimental  Facility  —  Phase  4 

(For  Use  of  Existing  Terminal  Equipment) 


General 
Research  Area 


SYSTEM  PERFORMANCE  STUDIES 


Performance  of 
Store-and-Forward 
Components  and 
Systems 


Summary  of  Research 
Activities: 

Development  of  functional  models 
Establishment  of  suitable  metrics 
Development  of  analytic  models 
Simulations 

Development  of  loading  and  measurement 
Instruments 

Perform  experimental  studies 


Performance  of  a 
Local  Area 
Network  System 


Performance  of  a 
Token  Passing  Ring 
Repeater/Extender 


Results: 

Performance  of  a 
Local  Area  Network  System 

•  The  delays  caused  by  the  virtual 

circuit  processes  were  1,000  time 
larger  than  those  attributable  to  cable 
access  and  transmission. 

•  The  delay  values  were  strongly 

clustered  around  multiples  of  30  ms. 


Results: 

Performance  of  a 
Token  Passing  Ring 
Repeater/Extender 

•  The  encoding  scheme  utilized  on  the 

fiber  link  caused  cascading  of  errors, 
i.e.  long  error  bursts 

•  The  encoding  scheme  was 
incompatible  with  DS2  framing 

•  Some  of  the  TPR  adapter  cards  could 
not  operate  with  maximum  specified 
delays 


Technical  Issues  in  Evolving  to 
Integrated  Services 
Digital  Networks  (ISDN) 

Appendix  F 

November  1989  Project  Review 


" Technical  Issues  in 
Evolving  to 
Integrated  Services 
Digital  Network  (ISDN)” 

Contract  Number:  DAKF11-86-D-001 5-0022 
GIT  Project  Numbers: 
E-21-F31(Elec  Engr)  and  G-36-615  (ICS) 


GIT  —  ISDN  Research 

Project 

BellSouth  Interests 

GIT  Project  Number: 

G-36-622 


20  November,  1989 


Informal  IPR 


The  Central  Node  (ICS) 

••  ISDN  PCs 

•  ••  AMD  Boards  (Limited  software  capabilities) 

•  ••  Hayes  Boards  (Limited  software  capabilities) 

•  ••  Northern  Telecom  Boards  (With  software) 
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Higher  Level  Software 

...  Touch  Communications  (Source  of  GOSIP  and  ISDN  S/W) 
•  ••  Vadis  (some  capability) 


The  AIRMICS  Node 
••  ISDN  PCs 

•••  Zenith  PCs  (On-order) 

•••  AMD  Boards  (Limited  software  capabilities) 

•••  Northern  Telecom  Boards  (With  software) 
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The  EE  Node 
••  ISDN  PCs 

•••  PCs  (To  be  ordered) 

•  ••  AMD  Boards  (Limited  software  capabilities) 

Northern  Telecom  Boards  (With  software) 
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Projected  Interconnection  Studies 


Technical  Issues  in  Evolving  to 
Integrated  Services 
Digital  Networks  (ISDN) 

Appendix  G 

March  1990  Project  Review 


Welcome 


to  the 

Georgia  Tech 
ISDN  Research  Project 

In-Progress  Review 
15  March,  1990 


Agenda 


1:00-1:15 

1:15-1:30 


1:30-2:00 

2:00-2:20 

2:20-2:40 

2:40-3:30 

3:30-4:00 

3:30-4:30 


Registration 

Welcome 

Jay  Gowens,  AIRMICS 
Neale  Hightower,  BellSouth 
What  is  ISDN 
Phil  Enslow,  GIT 

Project  Introduction  and  Overview 
Phil  Enslow,  GIT 
Break 

Project  Results  and  Plans 
Phil  Enslow,  GIT 
AIRMICS  Meeting  (DOD) 

Jay  Gowens,  AIRMICS 
Demonstrations 
Ron  Hutchins,  GIT 


What  is  ISDN? 


ISDN  —  CCITT  Definition 


IRSSSa 


The  ISDN  Subscriber  Interfaces 


Physical 


Two  Pain,  *ach  SX,  i.ftUMbpc 


#1  B-Ch*nn#t,  64kbpa 

<3  BOtannot,  fctkbpa 
« 

#22  S~Chanh«4,  (4  kbpa 
923  B-Cf2*nn*1,  ft4  kbpa 
O-Ch mumI,  Mkbpa 


!W.ya-J|! 


An  ISDN  Terminal  —  "TE1" 


Major  Changes  in 
Subscriber  Interface 


Delivery 

Uses  existing  2-wire  distribution  loops 
Digital  signal  delivered  to  subscriber 
Multiple  service  channels  over  one  physical  path 
Variety  of  services  available  on  each  channel 

Signaling  and  Control 
Out-of-Band  (c.I.  present  In-Band) 

Shared  Control  Channel 
Increased  control  capabilities 


ISDN  S-BUS  CONNECTIONS 

(Only  2  Terminals  are  Shown.  Eight  are  possible) 
ISDN — Term  ISDN — Network  Term 


■HfikBI-iiiil 


The  "ISDN" 

An  Enhanced  Capability  Central  Office 


The  ISDN  central  office  Is  one  of  the  major 
and  critical  components  of  the  ISDN  evolution 

New  capabilities  required  In  the  ISDN  switch: 
Handle  digital  subscriber  lines 
Handle  user  control 
Support  shared  use  of  the  D-channe! 


Putting  ISDN  Into  Perspective 
Comments  on  Results  of  Evolution 

1.  Voice  orientation  of  most  subsystems  and  the 
evolution  results  In  service  channels  of 

64  Kbps  or  multiples  ol  64  Kbps. 

For  voice  —  too  big  (tor  current  voice  tech) 

For  data  —  loo  small  (for  many  new  appls) 

2.  32  Kbps  voice  being  introduced 

-  Problems  tor  use  with  some  modems 

-  Not  an  “ISDN"  product  but  being 
“blamed"  on  ISDN 


IBS8S3I 


ISDN— What  It  Is 

In  tag  rated  Digital  Access  to  ALL  Services 
Potential  lor  Increased  subscriber  control 
A  series  ol 

CCITT  Recommendations  —  The  "t-Series" 
Amplified  by  O.S.  Standards  —  T1 

Telecommunications  Services 

Telematic  Services 


ISDN— What  It  Is  Not 


Not  a  sudden  change  ot  the  entire  system 
Primarily  evolution  ol  the  existing  systems 
Already  here: 

Digital  Trunking 
Digital  Switches 
The  IDN 

Major  changes  yet  to  come: 

Integrated  end  Digital  Access 
New  Subscriber  Access  Protocols 
Increased  Subscriber  Control  Capabilities 

Not  a  major  change  In  Subscriber  Telecom  Services 
Ex:  32  Kbps  voice  Is  not  “ISDN" 


A  Joint 


Project  Results 

In-Progress  Review 
15  March,  1990 


Project  Results 

Outline 

Establishment  of  the  ISON  Experimental  Facility 

Installation  of  ISDN  Hardware,  Software,  and 
Services 

Utilization  of  ISON  Services 

Studies  of  ISON  Protocols 

Preparation  of  an  ISDN  Users'  Handbook 


BSSPli 


Establishment 

of 

ISDN  Experimental  Facility 


ISDN  Experimental  Facility 


Create  an  Instrumented  ISDN  Applications  Test  Facility 
that  will  support  the  detailed  examination  of  ISON 
services  and  their  applicability 

Record  and  examine  the  problems  encountered  In 
Installing  and  utilizing  ISDN  services 

Support  experimental  studies  of  ISDN  protocols 


rVrVa- 


ISDN  Experimental  Facility 


Con*g* 
of  Computing 


ISDN  Experimental  Facility 


Load  generators  and  testers 

Through  pert  and  Oallvary  D«Uy 
Charactars  and  Packata 

Error/Noise  Injectors 

S-Bua 


NeXT  Computer  ISDN  Interface  Board 


ISDN  Experimental  Facility 


NaXT 
Cam  polar 


Provide  several  levels  of  connectivity 

Local 
Commit 
Puwie  Nar worn 

Full  experimental  freedom 

Teutfy  tooiatad,  local  and  campus  eon  nact  Iona 

Teet  eppllceblllty  of  ISDN  to  specific  epplicetlona 
Operetlonel  test  of  ISDN  herdwere  end  software 


SftsffiicW! 


Q5§l 


Installation  of  ISDN  Hardware, 
Software,  and  Services 


ISDN  Hardware  and  Software 


PC  ISDN  Terminal  Adapter  Boards 
ISDN  Central  Office  Unas 
Office  Distribution  of  ISDN  Lines 


Hardware  compatibility  problems 

Clock  rataa 

Oasianaiton  el  tha  rSON  port 
Conflict*  with  otnar  davicaa 

Software  Interfaces 

Vartad  Non-Standard 

Two  "NETBIOS”  not  lha  sama 

We  have  no!  yet  achieved 
Interoperation  between  two 
vendors 


ISDN  Hardware  and  Software 


Features/options  available 
Very  large  number  available 

Necessity  to  completely  specify  the 
configuration 

Assignment  of  B-Channels  to  Terminals 

Nol  dynamic 

Hum  MMgnMe  Tee Set  •'  or  ‘CWult  r 

Allocation  of  telephone  numbers  (DNAs) 
Lknas  numew  ot  «<Km  aBowad  an  bun 


|W& 


Utilization  of  ISDN  Services 

Summary 

Utilizing  a  PC  on  ISDN 
Error  recovery  times 


Utilization  of  ISDN  Services 


Reaction  to  Intentionally  forced  errors 

DvpBeats  TCI  assignment 

Central  OHIcs  switch  resets  and  runs  diagnostics 
— II  mint  or  so 

Disconnect  -  as.  moving  s  phone 

interpreted  as  UNK  DOWN  and  CO  roosts 

Results  of  system  errors  not  yet  observed 


Studies  of  ISDN  Protocols 
Summaa 

Analytic  Studies 
Simulations 

Protocol  Stability  and  Robustness 


Studies  of  ISDN  Protocols 

Simulations 


D-Channet  Data  Transtar  Protocol 


Preparation  of  ISDN  Users'  Handbook 


This  will  ba  a  collection  of  facts, 
experiences,  tips,  etc.  acquired 
during  all  phases  of  this  projed 


Project  Plans 

In-Progress  Review 
15  March,  1990 


Mva- 


Project  Plans 

Summary 

Exploitation  of  The  Experimental  Facility 
Integrated  ISON  Connectivity 
LANs  and  ISON 

Development  of  Standard  tSDN  Software  Interface 
Development  of  operational  test  specifications 
lisa  of  ISON  In  private  networks 
Control  Interfaces  to/from  Public  ISON  Networks 
"Technical"  Participation  in  the  NIU 

HrVrVe- 


Integrated  ISDN  Connectivity 


The  user  of  ISON  services  must  be 
provldied  with  the  same  interface  as 
the  user  of  all  other  Interconnection 
services. 

A  variety  of  special  procedures  is 
unacceptable. 

Work  Is  required  to  develop  a 
consistent  and  common  user  Interface. 


Project  Plans 


I  «  ItlrMKI  »1a  | 


What  will  be  the  role  and  usefulness  of 
ISON  with  respect  to  Local  Area  Networks? 

t*t*reonn#ei  (brMga)  fwo  LANs 

Elttnd  •  LAN 
R«ptCO*  tft«  LAN 


LANs  and  ISDN 


ISDN 


Project  Plans 


I i il4il «.*J  mri I ilrf 1 £"M--T«m7(  U  M  Tim i- K  j 


Today,  multiple  interlaces  to  TA  Boards  are  encountered 
BitwMfl  v*ndom 
With*  on#  V*«Oor 


Lack  of  a  standard  ISDN-API  Is  a  great  Impediment  to 
production  of  ISON  applications  packages 

Target  environments 

GOSIP  (OSO 

tcp/ip 

0«  facto  ottfa  - 


ipisgsapi! 


Project  Plans 


Individual  Subscriber  to/from  Public  ISDN  Networks 

Private  Networks  to/from  Public  ISON  Networks 

"Control"  of  Private  Networks  Implemented  on 
Public  ISON  Networks  (Virtual  Private  Nets) 


liW*  ! 


